Messages in this thread | | | Subject | Re: [PATCH] printk: stop spining waiter when console resume to flush prb | From | luojiaxing <> | Date | Fri, 7 May 2021 15:33:26 +0800 |
| |
On 2021/5/6 22:12, Sergey Senozhatsky wrote: > On (21/05/06 23:07), Sergey Senozhatsky wrote: >> Can we count the number of lines that we print from the `current` context >> in console_unlock() and if after N messages there is no console_lock waiter >> waiting for the `current` to handover console lock ownership, then create >> one: schedule IRQ work that will become a console lock owner, spin on >> console lock and call console_unlock() once it acquired the ownership. >> That 'artificial' console lock owner will do the same - print N >> messages, if nothing wants to become a console lock owner then it'll >> queue another IRQ work. > Or even simpler > > console_unlock() > { > ... > > if (printed_messages > limit && !console_lock_spinning_disable_and_check()) { > printk_safe_exit_irqrestore(flags); > > console_locked = 0; > up_console_sem(); > > defer_console_output(); > return; > }
Hi, Sergey, I test this, it works.
But, I have a doubt. If the log buffer exceeds limit, we can schedule IRQ work to become the console lock owner and let current context return.
So why not just let the IRQ work process the console output without limit? To be clear, driver call printk() only care about the correct sequence of timestamps
and does not care when the print is output. Actually, I wonder if the driver can only cache the print and queue the output tasks to a workqueue to return, and then return directly?
I don't know if this is a stupid idea, because I'm not familiar with printk.
Thanks
Jiaxing
> ... > } > > . >
| |