lkml.org 
[lkml]   [2018]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On Thu, 11 Jan 2018 11:29:08 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> > claiming that for any given A, B, C the following is always true
> >
> > A * B < C
> >
> > where
> > A is the amount of data to print in the worst case
> > B the time call_console_drivers() needs to print a single
> > char to all registered and enabled consoles
> > C the watchdog's threshold
> >
> > is not really a step forward.
>
> It's no different than what we have, except that we currently have A
> being infinite. My patch makes A no longer infinite, but a constant.
> Yes that constant is mutable, but it's still a constant, and
> controlled by the user. That to me is definitely a BIG step forward.

I have to say that your analysis here really does point out the benefit
of my patch.

Today, printk() can print for a time of A * B, where, as you state
above:

A is the amount of data to print in the worst case
B the time call_console_drivers() needs to print a single
char to all registered and enabled consoles

In the worse case, the current approach is A is infinite. That is,
printk() never stops, as long as there is a printk happening on another
CPU before B can finish. A will keep growing. The call to printk() will
never return. The more CPUs you have, the more likely this will occur.
All it takes is a few CPUs doing periodic printks. If there is a slow
console, where the periodic printk on other CPUs occur quicker than the
first can finish, the first one will be stuck forever. Doesn't take
much to have this happen.

With my patch, A is fixed to the size of the buffer. A single printk()
can never print more than that. If another CPU comes in and does a
printk, then it will take over the task of printing, and release the
first printk.

-- Steve

\
 
 \ /
  Last update: 2018-01-14 23:25    [W:0.188 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site