lkml.org 
[lkml]   [2022]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH printk v4 00/15] implement threaded console printing
On Fri 2022-04-22 11:39:59, Petr Mladek wrote:
> On Thu 2022-04-21 23:28:35, John Ogness wrote:
> > This is v4 of a series to implement a kthread for each registered
> > console. v3 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 version looks good enough for linux-next. I do not see any
> functional problem and it should work as designed. It is time to
> see how it works in various "real life" work loads.
>
> I am going to push it later today unless anyone (John) complains ;-)

I have pushed the patchset into printk/linux.git, branch
rework/kthreads. Also I merged it into for-next branch.

We are still discussing better solution of the complicated locking
scheme[0]. The main purpose is to make it easier and more safe to use.
Anyway, the current code looks safe. Any potential improvements
should not affect the behavior.

So, it is time to test it in linux-next. Let's see how survives
hammering of various robots and people testing on linux-next.
I keep my fingers crossed.

Best Regards,
Petr

\
 
 \ /
  Last update: 2022-04-22 23:36    [W:0.285 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site