Re: [PATCH RFC] printk: remove BOOT_PRINTK_DELAY

[Petr Mladek]

On Wed 2026-05-06 23:37:01, Andrew Murray wrote:
> On Tue, 5 May 2026 at 15:26, Petr Mladek <pmladek@xxxxxxxx> wrote:
> >
> > On Tue 2026-05-05 14:45:00, Andrew Murray wrote:
> > > The CONFIG_BOOT_PRINTK_DELAY option enables support for the boot_delay
> > > kernel parameter, this allows for a configurable delay to be added before
> > > each and every printk is emitted. This is DEBUG_KERNEL option that is
> > > helpful for debugging as kernel output can be slowed down during boot
> > > allowing messages to be seen before scrolling off the screen, or to
> > > correlate timing between some physical event and console output.
> > >
> > > However, since the introduction of nbcon and the legacy printer thread for
> > > PREEMPT_RT kernels, printk records are now emited to the console
> > > asynchronously to the caller of printk and its boot_delay. The delay added
> > > by boot_delay continues to slow down the calling process, but may not have
> > > any impact to the rate in which records are emited to the console. For
> > > example, if delay_use is set to 100ms, and the printer thread has a
> > > backlog of more than 100ms, perhaps due to a slow serial console, then the
> > > records will appear to be printed without any delay between them.
> > >
> > > It would be unhelpful to add a delay to the printer thread, and it would
> > > not be possible to disallow selection of CONFIG_BOOT_PRINTK_DELAY at build
> > > time as it's not possible to detect which consoles are nbcon enabled at
> > > build time. Therefore, let's remove this feature.
> >
> > Heh, Randy proposed to remove "boot_delay" few days ago.
> > This RFC goes even further and remove both "boot_delay" and
> > "printk_delay".
> 
> Apologies, I didn't see this. I'll co-ordinate with Randy.

No need to apologize.

> > Honestly, I do not feel comfortable by this. The delay seems to
> > be handy when there is only graphical console. I would suggest
> > to do:
> >
> >    1. Obsolete "boot_delay" with "printk_delay" as
> >       proposed in Randy's thread, see
> >       https://lore.kernel.org/all/afn2sYKKsqG4QBVX@xxxxxxxxxxxxxxx/
> 
> Your suggestion was:
> 
> " 1. Add "printk_delay" early_param() which would allow
>      to set "printk_delay_msec" via command line."
> 
> And I assume the intent is to replicate the functionality of
> boot_delay, by allowing printk_delay to be used to introduce delays
> from early_param time? Thus deprecating delay_use.

Exactly.

> 
> "  2. Modify boot_delay_setup() to set "printk_delay_msec" as well.
>      In addition, it might print a message that it has been
>      obsoleted by "printk_delay" and will be removed."
> 
> Given the intent may be to deprecate boot_delay, I'm not sure that
> setting printk_delay_msec as well would be beneficial, as this would
> extend its functionality to add delays beyond SYSTEM_RUNNING which is
> where boot_delay stops. Unless you mean to use boot_delay as an alias
> to an early_param hook for printk_delay?

I do not think that this is a big problem. As you write below, it is
a debug feature. IMHO, people debugging boot problems won't mind when
the delay continues beyond SYSTEM_RUNNING. And if anyone complains
than we would at least know that there are people using this feature ;-)

> It seems that there are also differences in behavior between
> printk_delay and boot_use, with printk_delay unconditionally adding
> delays to all printks, and delay_use which considers the loglevel.

The unconditional delay does not make much sense. I consider it a bug.

> >
> >    2. Move printk_delay() from vprintk_emit() to
> >       console_emit_next_record() and nbcon_emit_next_record().
> >
> >       For nbcon console, even better would be to use a sleeping
> >       wait in nbcon_kthread_func(). But it would need some
> >       changes to call it only when a record was really emitted.
> >       Also we would need to use the busy wait in
> >       __nbcon_atomic_flush_pending_con().
> 
> This makes sense.
> 
> If the use case (in a post kthread printk thread world), is only
> relevant for graphical consoles, then I do wonder if printk_delay and
> boot_delay can be replaced with a more specific solution? Now that we
> have printk threads, the time in which a printk is presented to the
> user may not relate to when it was created, and I fear people may
> continue to debug issues that rely on that assumption.
> 
> I think the most pragmatic solution for now is:
> - Move the printk delay to the point where the printk is actually
> printed (e.g. console_flush_one_record and descendants)
> - Add an early_param to allow for printk_delay_msec to be set
> - Deprecate boot_delay, by using it as an alias for setting
 > printk_delay_msec, and include a user mesage that it is being
> deprecated and that it now extends to beyond boot (which could impact
> performance on non PREEMPT_RT and non nbcon systems)

Sounds good.

> - Update printk_delay function to use the appropiate mechanism to
> delay based on stage of boot and using printk_delay_msec instead of
> boot_delay.

Good point! I thought that mdelay() can be used even for the early
messages because parse_early_param() is called right before
parse_args() in start_kernel() in init/main.c.

But parse_early_param() might be called even earlier, for example,
by setup_arch in arch/x86/kernel/setup.c. And it is called before

  + tsc_early_init()
    + tsc_enable_sched_clock()
      + loops_per_jiffy = get_loops_per_jiffy()

which seems to be used by

  + mdelay()
    + udelay()
      + __const_udelay()

Anyway, it has to be done before printk_delay_msec() can be set
via an early parameter.

> If that makes sense I can fashion a patchset.

That would be great.

Best Regards,
Petr

PS: Note that I am traveling the following week so my review might
    get delayed.