From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751822AbdCYTql (ORCPT ); Sat, 25 Mar 2017 15:46:41 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:20961 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751772AbdCYTqj (ORCPT ); Sat, 25 Mar 2017 15:46:39 -0400 Subject: Re: [v2 0/9] Early boot time stamps for x86 To: Thomas Gleixner References: <1490368899-877997-1-git-send-email-pasha.tatashin@oracle.com> Cc: x86@kernel.org, LKML , mingo@redhat.com, Peter Zijlstra , "H. Peter Anvin" From: Pasha Tatashin Message-ID: Date: Sat, 25 Mar 2017 15:45:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, Thank you very much for a very insightful feedback. I will address your comments, and if I have any questions, I will ask them before sending out the next patchset. A few replies below: > First of all, this "solution" is only valid for a very restricted set of > systems and breaks others in very subtle ways. > > FYI, the architecture name is x86, which handles 32bit/64bit, various > vendors and hypervisors. It's not 'arch/mymachine'. The reason why I only targeted newer processors and 64-bit platforms was because these are the machines that keep growing in size: more memory, cpu count etc. Which, means these are the machine where we can get scalability problem in the future. > > So this needs to be integrated into the existing TSC/CPU calibration > mechanism which works across all supported systems. And that means, that > early TSC calibration can't be done before x86_init.oem.arch_setup() and > hypervisor_init_platform() have been invoked. > > By that time, which is still pretty early in the boot process: > > - boot_cpu_data has been preinitialized > > - calibration functions setup has been done This sounds good. I will sanity check that we do not spend excessive amount of time before x86_init.oem.arch_setup() is done on some larger machines, and will start early clock sometime after this call is finished. > Putting the early TSC initialization after hypervisor_init_platform() makes > this available for _ALL_ systems/platforms as infrastructure and allows the > platforms to add the required bits of support via a new set of function > pointers in struct x86_platform_ops, which btw. is a proper form of > abstraction. Ok > The time between x86_64_start_kernel() and that point is in the low single > digit millisecond range or less than a millisecond and therefor completely > irrelevant. The first timestamps before that point will be 0 as they used > to be. > > You can argue in circles about that, it's simply not debatable. Sure, I tried perfection by having timestamps available with the first log message, but your proposed practicality makes sense. > But that's only the sched clock part of the problem. If this early > sched_clock() is available, then this needs to be fed into the setup of > timekeeping as well, otherwise dmesg tells 50 seconds into boot and clock > monotonic/boottime say 5, which would be confusing at best. That has not be > solved in the first step, but definitely before something like this is > going to be merged. Thank you for catching this, I will make sure boottime/dmesg times match. Thank you, Pasha