[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180110184144.GR6176@hirez.programming.kicks-ass.net>
Date: Wed, 10 Jan 2018 19:41:44 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Tejun Heo <tj@...nel.org>
Cc: Petr Mladek <pmladek@...e.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
akpm@...ux-foundation.org, Steven Rostedt <rostedt@...dmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
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>, 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>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On Wed, Jan 10, 2018 at 10:30:55AM -0800, Tejun Heo wrote:
> > Why not kill recursive OOM (msgs) ?
>
> Sure, we can do that too, e.g. marking flushing thread and ignoring
> new messages from it, although that does come with its own downsides.
Typically we (scheduler) have removed printk()s (on boot) when BIGSMP
folks say it creates boot pain. Much of it is now behind the sched_debug
parameter, others are compressed.
I've also seen other people reduce printk()s.
In general reducing printk() is a good thing, its a low bandwidth
channel for critical stuff like OOPSen and the like.
Powered by blists - more mailing lists