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
On 2022-04-21, Petr Mladek <[email protected]> wrote:
> 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.
Even though the fixup may be straight-forward, it would be touching a
lot of lines and could potentially introduce new problems. I prefer you
wait for a v4 so that there is no mess to clean up.
I can post a v4 tomorrow (using option #1 from [0] as the
synchronization alternative).
John
[0] https://lore.kernel.org/r/[email protected]