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

John Ogness
2026-03-26T09:24:59Z

Hi Tim,

On 2026-03-24, "Bird, Tim" <Tim.Bird@sony.com> wrote:
> Yeah - I was worried about other timestamps not being in synchronization
> with my adjusted printk timestamps. Looks like that worry was justified.
>
> At this point, there are two avenues:
>
> 1) double-down and embed the offset (from power-on rather than from time_init)
> all the way into local_clock() and/or whatever is providing CLOCK_MONOTONIC
> and CLOCK_BOOTTIME, or
>
> 2) back off, and abandon adding the offset to local_clock()-based printk timestamps.
> This would leave a discontinuity when EARLY_PRINTK_TIMES was enabled,
> between the (now) non-zero early printk timestamps and the ones following
> time_init(). This has the benefit of changing less code, and only affecting
> the early printk timestamps (and none of the rest of the system). And it has
> the downside of leaving the possibly confusing time discontinuity
> early in the kernel log. So far, I haven't seen any tools confused by this, and
> I can put a message before time_init() to inform humans about the switch.
>
> The purpose of this patch is really focused on that early period of boot, where all
> other timing and tracing mechanisms are unavailable, and limiting the impact to
> just those early (currently zero) timestamps seems like the best course.

I have always felt that printk timestamping should be using a
userspace-accessible clock, such as CLOCK_MONOTONIC, rather than the CPU
local clock. This simplifies applications coordinating their own logs
with raw kernel logs.

I was wondering if your pre-boot timing could be used as the init values
for CLOCK_MONOTONIC, so that CLOCK_MONOTONIC is a clean continuation of
your pre-boot clocking.

And then we could use this opportunity to switch printk to
CLOCK_MONOTONIC.

This might also make sense if initializing CLOCK_MONOTONIC is somehow
more straight forward that tracking an extra CPU local clock diff.

John Ogness