Messages in this thread | | | Date | Thu, 21 Apr 2022 16:40:25 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH printk v3 00/15] printk/for-next |
| |
On Wed 2022-04-20 01:52:22, John Ogness wrote: > This is v3 of a series to implement a kthread for each registered > console. v2 is here [0]. The kthreads locklessly retrieve the > records from the printk ringbuffer and also do not cause any lock > contention between each other. This allows consoles to run at full > speed. For example, a netconsole is able to dump records much > faster than a serial or vt console. Also, during normal operation, > printk() callers are completely decoupled from console printing. > > There are situations where kthread printing is not sufficient. For > example, during panic situations, where the kthreads may not get a > chance to schedule. In such cases, the current method of attempting > to print directly within the printk() caller context is used. New > functions printk_prefer_direct_enter() and > printk_prefer_direct_exit() are made available to mark areas of the > kernel where direct printing is preferred. (These should only be > areas that do not occur during normal operation.) > > This series also introduces pr_flush(): a might_sleep() function > that will block until all active printing threads have caught up > to the latest record at the time of the pr_flush() call. This > function is useful, for example, to wait until pending records > are flushed to consoles before suspending. > > Note that this series does *not* increase the reliability of console > printing. Rather it focuses on the non-interference aspect of > printk() by decoupling printk() callers from printing (during normal > operation). Nonetheless, the reliability aspect should not worsen > due to this series.
This series looks almost ready for linux-next. The only real problems are:
+ Use allow_direct_printing() instead of atomic_read(&printk_prefer_direct) in defer_console_output()
+ "temporary" remove console_lock_single_hold()/console_lock_single_release() and use the full console_lock()/console_unlock() instead.
The rest are few cosmetic issues.
I would like to push this into linux-next ASAP so that we get some wider testing of this approach. I do not expect that we could find much more issues just by staring into the code ;-)
Now, the question is whether I should wait for v4. Or whether I should put v3 into linux-next with a follow up patch doing the two above suggested changes. They are quite trivial.
Anyway, if I pushed v3+fixup then I would replace it with v4, v5, ... once they are available. I just do not want to block testing because of cosmetic problems.
John, what is your preference, please? Anybody has another opinion, please?
Best Regards, Petr
| |