lkml.org 
[lkml]   [2017]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [v2 0/9] Early boot time stamps for x86
From
Date
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

\
 
 \ /
  Last update: 2017-03-25 20:47    [W:0.185 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site