Re: [PATCH v3] printk: fix zero-valued printk timestamps in early boot

Thomas Gleixner
2026-03-26T13:17:04Z

On Tue, Feb 10 2026 at 16:47, Tim Bird wrote:
> During early boot, printk timestamps are reported as zero before
> kernel timekeeping starts (e.g. before time_init()). This
> hinders boot-time optimization efforts. This period is about 400
> milliseconds for many current desktop and embedded machines
> running Linux.
>
> Add support to save cycles during early boot, and output correct
> timestamp values after timekeeping is initialized. get_cycles()
> is operational on arm64 and x86_64 from kernel start. Add code
> and variables to save calibration values used to later convert
> cycle counts to time values in the early printks. Add a config
> to control the feature.
>
> This yields non-zero timestamps for printks from the very start
> of kernel execution. The timestamps are relative to the start of
> the architecture-specified counter used in get_cycles
> (e.g. the TSC on x86_64 and cntvct_el0 on arm64).
>
> All timestamps reflect time from processor power-on instead of
> time from the kernel's timekeeping initialization.

Can we pretty please _not_ introduce yet another side channel to
generate time stamps?

printk()

time_ns = local_clock();

local_clock()
local_clock_noinstr()
// After boot
if (static_branch_likely(&__sched_clock_stable))
return sched_clock_noinstr() + __sched_clock_offset;

// Before sched_clock_init()
if (!static_branch_likely(&sched_clock_running))
return sched_clock_noinstr();

clock = sched_clock_local(this_scd());

On x86:
sched_clock_noinstr()
// bare metal
native_sched_clock()
// After TSC calibration
if (static_branch_likely(&__use_tsc)) {
...
}

// Jiffies fallback.

So the obvious solution is to expand the fallback with:

if (tsc_available())
return tsc_early_uncalibrated();

return jiffies ....;

As this needs to be supported by the architecture/platform in any case
there is close to zero benefit from creating complicated generic
infrastructure for this.

Thanks,

tglx