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

Steven!

On Tue, Mar 31 2026 at 20:05, Steven Rostedt wrote:
> On Wed, 01 Apr 2026 01:36:26 +0200
> Thomas Gleixner <[email protected]> wrote:
>> That's ~12ms of time which is not accounted for in the overall boot time
>> until the machine reaches the init process:
>> 
>> [   12.289141] Run /init as init process
>
> 12 seconds! Holly crap, that would fail every Chromebook requirement we
> have. In most cases, we shoot for a 3 second boot up and 8 second max.
> That's from hitting the power button to login screen. FYI, 30ms is
> considered a really long time.

Which 30ms are you talking about?

The first timestamp is 12ms into the boot on bare metal as you can see
from the quoted text above. On a 4 CPU VM running on that very same host
it's 15ms due to the VM exit costs.

Which means with your 3 seconds aim, that's ~0.4% of the overall
time. Even with your 30ms it's still only 1% according to my old school
understanding of math.

> Point being, I'm sure Tim is worried about devices that require fast boot
> up times. Not machines with 256 CPUs.

You're clearly missing the point.

As I've demonstrated the time until the first time stamp is available
has nothing to do with the number of CPUs and is more or less constant:

VM with 4 CPUs:

[    0.015122] last_pfn = 0x280000 max_arch_pfn = 0x400000000

VM with 32 CPUs:

[    0.015150] e820: remove [mem 0x000a0000-0x000fffff] System RAM

The costs of the number of CPUs comes later in the boot process:

VM with 4 CPUs:

[    0.995082] Run /init as init process

VM with 32 CPUs:

[    3.329398] Run /init as init process

No?

Thanks,

        tglx