Messages in this thread | | | Subject | Re: [v2 0/9] Early boot time stamps for x86 | From | Pasha Tatashin <> | Date | Sat, 25 Mar 2017 15:45:47 -0400 |
| |
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
| |