Re: [PATCH] mm, oom: enable rate-limiting controls for oom dumps

From: Petr Mladek <pmladek@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>,
	"Michal Hocko" <mhocko@suse.com>,
	akpm@linux-foundation.org, kernel@collabora.com, hch@lst.de,
	guro@fb.com, rientjes@google.com, mcgrof@kernel.org,
	keescook@chromium.org, yzaikin@google.com, linux-mm@kvack.org,
	"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
	"Steven Rostedt" <rostedt@goodmis.org>
Subject: Re: [PATCH] mm, oom: enable rate-limiting controls for oom dumps
Date: Thu, 15 Oct 2020 15:05:54 +0200	[thread overview]
Message-ID: <20201015130554.GF8871@alley> (raw)
In-Reply-To: <9cb10e17-ac04-9f7d-2138-cc044e2b080b@i-love.sakura.ne.jp>

On Tue 2020-10-13 19:46:32, Tetsuo Handa wrote:
> On 2020/10/13 18:02, Petr Mladek wrote:
> > On Tue 2020-10-13 09:40:27, Tetsuo Handa wrote:
> >> Proper ratelimiting for OOM messages had better not to count on asynchronous printk().
> > 
> > I am a bit confused. AFAIK, you wanted to print OOM messages
> > asynchronous ways in the past. The lockless printk ringbuffer is on
> > its way into 5.10. Handling consoles in kthreads will be the next
> > step of the printk rework.
> 
> What I'm proposing is synchronously printing OOM messages from a different
> thread, for one dump_tasks() call can generate thousands of lines which may
> significantly delay arrival of non OOM related messages to consoles (or even
> drop due to logbuf being full). I don't want to enqueue too many OOM related
> messages to logbuf, even after printk() became completely asynchronous.

This looks like a lot of complexity. I am not convinced that it is
worth it. I could understand that people heavily testing OOM behavior
meet this problem. But I wonder how many people really meet this
problem in the real life.

> > Could you please provide some examples how you would tune ratelimit
> > when printing all messages to the console takes X ms and OOM
> > happens every Y ms?
> 
> My proposal is to decide whether to print the new report based on
> whether all OOM candidates for that OOM domain have been flushed to
> consoles. There is no X and Y.

From the printk() point of view, we need an API that would provide
information whether a given message reached the consoles or not.
Then it would be up to the MM-code to use it.

One catch might be when console_seq is synchronized by console_lock.
Because the caller of this API would become responsible for flushing
all existing messages. But it should be usable. It is currently
synchronized also by logbuf_lock.

Best Regards,
Petr