Re: [v2 0/9] Early boot time stamps for x86

[Pasha Tatashin]

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