[lkml]   [2018]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Would you help to tell why async printk solution was not taken to upstream kernel ?
On Sun, 04 Mar 2018 23:08:23 +0800
"Qixuan.Wu" <> wrote:

> Suppose there is one scenario that the system has 100 CPU(0~99). While CPU 0 is
> calling slow console, CPU 1~99 are calling printk at the same time. And suppose
> CPU 1 will be waiter, as per the patch, 2~99 will return directly. After CPU 0 finish
> it's log to console, it will return when it finds CPU 1 are waiting. Then CPU 1 need
> flush all logs of CPU(1~99) to the console, which may cause softlockup or rcu
> stall. Above scenario is very unusual and it's very unlikely to happen.

Yes, people keep bringing up this scenario.

It would require a single burst of printks to all CPUs. And then no
more printks after that. The last one will end up printing the entire
buffer out the slow console. The thing is, this is a bounded time, and
no printk will print more than one full buffer worth.

If this is a worry, then set the timeouts for the lockup detection to
be longer than the time it takes to print one full buffer with the
slowest console.

-- Steve

 \ /
  Last update: 2018-03-04 16:44    [W:0.180 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site