Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

From: Sergey Senozhatsky
Date: Wed Mar 09 2016 - 01:08:51 EST

Hello Jan,

On (03/07/16 13:16), Jan Kara wrote:
> > So if this will be a problem in practice, using a kthread will probably be
> > the easiest solution.
> Hum, and thinking more about it: Considering that WQ_MEM_RECLAIM workqueues
> create kthread anyway as a rescuer thread, it may be the simplest to just
> go back to using a single kthread for printing. What do you think?

I have this patch on top of the series now. In short, it closes one more
possibility of lockups -- console_lock()/console_unlock() calls. the patch
splits console_unlock() in two parts:
-- the fast one just wake up printing kthread
-- the slow one does call_console_drivers() loop

I think it sort of makes sense to tweak the patch below a bit and fold it
into 0001, and move _some_ of the vprintk_emit() checks to console_unlock().

very schematically, after folding, vprintk_emit() will be

if (in_sched) {
if (!printk_sync && printk_thread)

if (!in_sched)
if (console_trylock())

and console_unlock() will be

if (!in_panic && !printk_sync && printk_thread) {
} else {

console_unlock_for_printk() does the call_console_drivers() loop.

console_flush_on_panic() and printing_func() call console_unlock_for_printk()

What do you think? Or would you prefer to first introduce async
printk() rework, and move to console_unlock() in vprintk_emit()
one release cycle later?
IOW, in 3 steps:
-- first make printk() async
-- then console_unlock() async, and use console_unlock_for_printk() in
-- then switch to console_unlock() in vprintk_emit().

below is the patch which introduces console_unlock_for_printk().
not the squashed console_unlock_for_printk() and 0001.