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

[Bird, Tim]

> -----Original Message-----
> From: John Ogness <john.ogness@xxxxxxxxxxxxx>
> Hi Tim,
> 
> On 2026-03-24, "Bird, Tim" <Tim.Bird@xxxxxxxx> 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.

That's interesting.  It does sound like it would solve the discontinuity problem.
However, this does fall in  the 'double-down' category of changes,
(ie embedding the offset from power-on provided by early cycles into CLOCK_MONOTONIC,
and making additional changes to printk to use that clock.)

I would have to do some more research on the clock system for this, and it's getting
a bit afield of my little patch to support getting timing info on 20 to 60 early boot printks.

> 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 than tracking an extra CPU local clock diff.

I'd have to figure out what clock is providing CLOCK_MONOTONIC, and see
how the initialization works.  In terms of complications, I'd guess it's about equal.
The code in my patch to add the early_times offset (early_ts_offset) should
resolve down to a single inline add (inside adjust_early_ts, inside print_time).

This add only happens for printk timestamps, so the overall effect on the system
is quite limited.  If we put the offset add into CLOCK_MONOTONIC, it will affect
all users (which, of course, is the point in order to harmonize timestamps between
printk and user-space, and possibly other timestamp users in the kernel).  But it
makes the effect more general. Since the purpose of the patch was just to
allow me to get timestamps for a small number of pre-time_init() printks, I really
wanted to minimize any long-term runtime impacts.

Having said that, I think it's likely there's already some offset calculation or scaling
that this might fold into for CLOCK_MONOTIC, where adjusting the offset to be
from power-on rather than from initializing of timekeeping would generate no actual
increase in the overhead of getting the CLOCK_MONOTONIC value.

I'll do some research and see if what I can find out, to see if that makes sense.
Overall, I think it would be a net positive if:
 - printk and user-space timestamps were harmonized
 - the time base for the system (0-time) was from power-on rather than from kernel
    timekeeping initialization.

Thanks for the ideas and feedback.
 -- Tim