Re: [PATCH v2] printk: Use two irq_works instead per-CPU

[Petr Mladek <pmladek@suse.com>]

On Mon 2026-09-14 16:34:12, Sebastian Andrzej Siewior wrote:
> In commit b845b517b5e37 ("printk: robustify printk") initially got its
> delayed wake up which is today implemented via the irq_work. Back then
> it was a variable which was assigned to 1 if a pending wake up was
> waiting. This variable was checked on each timer tick. Therefore it
> makes sense to assign a per-CPU variable with this task to avoid cache
> line bouncing when each CPU reads the variable on each timer tick
> simultaneously.
> 
> Today we have a irq_work which is enqueued onto a list and handled if it
> has work items assigned. This list is already per-CPU.
> 
> We could replace the per-CPU irq_work and the per-CPU printk_pending with
> two irq_work structs: One for PRINTK_PENDING_WAKEUP and the other for
> PRINTK_PENDING_OUTPUT.
> While unrolling the conditions in __wake_up_klogd() it becomes obvious
> that PRINTK_PENDING_WAKEUP is always passed as an argument but never
> checked. The return value wq_has_sleeper() of does not really matter
> it's sole purpose is to enforce the needed memory barrier.
> 
> Redo the irq_work by:
> - Use one irq_work (pending_wakeup_work) for klogd wakes. Schedule it
>   only if there is a sleeper waiting.
> - Use one irq_work (&pending_output_work) for output printing. Schedule
>   it only if PRINTK_PENDING_OUTPUT passed.
> - Drop unused PRINTK_PENDING_WAKEUP.
> - Remove the preempt_disable() section. Its purpose was to ensure that
>   printk_pending and wake_up_klogd_work is accessed from the same CPU.
> 
> Worst case is defer_console_output() where two irq_work are scheduled but
> those get processed one after the other during the HZ tick so it
> shouldn't get worse.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

I like this a lot. I always thought that using per-CPU variable was an
overkill. I had the clean up of this code on my TODO list for a
long time but I never came to it.

It looks good to me.

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

PS: I am going to wait few more days and give others chance to look at
    it. I will commit it next week if nobody complains.