Re: [RFC PATCH] mm, oom: oom ratelimit auto tuning

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Yafang Shao <laoar.shao@gmail.com>, Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>, Petr Mladek <pmladek@suse.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC PATCH] mm, oom: oom ratelimit auto tuning
Date: Wed, 15 Apr 2020 14:58:22 +0900	[thread overview]
Message-ID: <634bab6a-fee1-45b8-62af-be03062ae2bf@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <CALOAHbBsdEH4YAFefybV7sOLB0BH3H5ry1gQdb0+JW270Qpffw@mail.gmail.com>

On 2020/04/14 23:58, Yafang Shao wrote:
>>>>> The OOM ratelimit starts with a slow rate, and it will increase slowly
>>>>> if the speed of the console is rapid and decrease rapidly if the speed
>>>>> of the console is slow. oom_rs.burst will be in [1, 10] and
>>>>> oom_rs.interval will always greater than 5 * HZ.
>>>>
>>>> I am not against increasing the ratelimit timeout. But this patch seems
>>>> to be trying to be too clever.  Why cannot we simply increase the
>>>> parameters of the ratelimit?
>>>
>>> I justed worried that the user may complain it if too many
>>> oom_kill_process callbacks are suppressed.
>>
>> This can be a real concern indeed.

I'm proposing automated ratelimiting of dump_tasks() at
http://lkml.kernel.org/r/1563360901-8277-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp .
I believe that automated ratelimiting of dump_tasks() remains necessary
even after printk() became asynchronous.

>>
>>> But considering that OOM burst at the same time are always because of
>>> the same reason,
>>
>> This is not really the case. Please note that many parallel OOM killers
>> might happen in memory cgroup setups.
>>
>>> so I think one snapshot of the OOM may be enough.
>>> Simply setting oom_rs with {20 * HZ, 1} can resolve this issue.
>>
>> Does it really though? The ratelimit doesn't stop the long taking
>> output. It simply cannot because the work is already done.
>>
>> That being said, making the ratelimiting more aggressive sounds more
>> like a workaround than an actual fix. So I would go that route only if
>> there is no other option. I believe the real problem here is in printk
>> being too synchronous here. This is a general problem and something
>> printk maintainers are already working on.
>>
> 
> Yes, printk being too sync is the real issue. If the printk an be
> async, then we don't need to worry about it at all.

I strongly disagree. dump_tasks() will needlessly fill printk() log buffer
(and potentially loose other kernel messages due to buffer full / disk full).

By the way, Petr and Sergey, how is the progress of making printk() asynchronous?
When can we expect that work to be merged?