[PATCH RFC] printk: remove BOOT_PRINTK_DELAY

[Andrew Murray]

On Tue, 5 May 2026 at 15:26, Petr Mladek <pmladek at suse.com> 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.


>
> 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@pathway.suse.cz/

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.


"  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?

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.

With this approach, existing delay_use users will have the
inconvenience of having printk delays post SYSTEM_RUNNING. However, as
this is a DEBUG_KERNEL feature, maybe we don't need to preserve
behavior. Additionally, with the proposed changes for moving the
delays from printk time to console_flush_one_record time, the impact
for an uninformed user isn't as drastic.


>
>    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)
- 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.

If that makes sense I can fashion a patchset.

>
> IMHO, the only drawback might be that the delay might be multiplied
> when more consoles are registered. But I would ignore it. People
> would use this option only when the graphical console is the only
> one. It does not make sense for serial or network consoles.
>
> Best Regards,
> Petr

Thanks,

Andrew Murray