[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180111203057.5b1a8f8f@gandalf.local.home>
Date: Thu, 11 Jan 2018 20:30:57 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Petr Mladek <pmladek@...e.com>, Tejun Heo <tj@...nel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
akpm@...ux-foundation.org, linux-mm@...ck.org,
Cong Wang <xiyou.wangcong@...il.com>,
Dave Hansen <dave.hansen@...el.com>,
Johannes Weiner <hannes@...xchg.org>,
Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
Vlastimil Babka <vbabka@...e.cz>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jan Kara <jack@...e.cz>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
rostedt@...e.goodmis.org, Byungchul Park <byungchul.park@....com>,
Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On Thu, 11 Jan 2018 11:29:08 -0500
Steven Rostedt <rostedt@...dmis.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
Powered by blists - more mailing lists