On 15/06/16 11:26, Jan Beulich wrote: > Using the bare return value from read_platform_stime() is not suitable > when local_time_calibration() is going to use its fast path: Divergence > of several dozen microseconds between NOW() return values on different > CPUs results when platform and local time don't stay in close sync. > > Latch local and platform time on the CPU initiating AP bringup, such > that the AP can use these values to seed its stime_local_stamp with as > little of an error as possible. The boot CPU, otoh, can simply > calculate the correct initial value (other CPUs could do so too with > even greater accuracy than the approach being introduced, but that can > work only if all CPUs' TSCs start ticking at the same time, which > generally can't be assumed to be the case on multi-socket systems). > > This slightly defers init_percpu_time() (moved ahead by commit > dd2658f966 ["x86/time: initialise time earlier during > start_secondary()"]) in order to reduce as much as possible the gap > between populating the stamps and consuming them. > > Signed-off-by: Jan Beulich Subject to the style issue spotted by Joao, Reviewed-by: Andrew Cooper