[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171219010959.GA17164@jagdpanzerIV>
Date: Tue, 19 Dec 2017 10:09:59 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tejun Heo <tj@...nel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Rafael Wysocki <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread
On (12/18/17 15:10), Petr Mladek wrote:
[..]
> > All this is in the current upstream code as well. Steven's patch
> > should make it better in compare with the current upstream code.
> >
> > Sure, the printk offload approach does all these things better.
> > But there is still the fear that the offload is not reliable
> > in all situations. The lazy offload should handle this well from
> > my POV but I am not 100% sure.
>
> BTW: There is one interesting thing. If we rely on the kthread
> to handle flood of messages. It might be too slow because it
> reschedules. It might cause loosing messages. Note that
> the kthread should have rather normal priority to avoid
> blocking other processes.
... and this is why preemption is disabled in console_unlock()
in the patch set I have posted.
obviously you haven't even looked at the patches. wonderful.
-ss
Powered by blists - more mailing lists