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

Bird, Tim
2026-03-27T18:05:50Z

> -----Original Message-----
> From: John Ogness <john.ogness@linutronix.de>
> 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.

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