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

[Yafang Shao <laoar.shao@gmail.com>]

On Wed, Apr 15, 2020 at 1:58 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> 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.
>

Thanks for your information.
I haven't read your proposal carefully, but take a first glance I
think it would be a useful improvement.


> >>
> >>> 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).
>

Yup, printk() log buffer will be a issue if the console is too slow.
After the printk() is implemented as async, I thinks it is worth to do
some optimization.

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



Thanks
Yafang