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

Hi Tim,

On 2026-03-24, "Bird, Tim" <[email protected]> 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