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

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

On Fri, Apr 17, 2020 at 9:04 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2020/04/17 20:57, Yafang Shao wrote:
> >>>>> 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.
>
> Thank you. That patch alone avoids just RCU stall. But
> https://lkml.kernel.org/r/7de2310d-afbd-e616-e83a-d75103b986c6@i-love.sakura.ne.jp and
> https://lkml.kernel.org/r/57be50b2-a97a-e559-e4bd-10d923895f83@i-love.sakura.ne.jp
> referenced from that thread allows defer printing of OOM victim candidates. And
>
> >>> 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.
>
> my suggestion is to offload printing of OOM victim candidates to a workqueue context.
> Then, even after printk() became asynchronous, that workqueue waits for completion of
> printing to consoles for each OOM victim candidate. This way, only dump_tasks() where
> dumping of past OOM-killer invocations has not completed will suppress dump_tasks()
>  from later OOM-killer invocations in a way duplicated OOM victims won't be reported
> for many times (and also saves printk() log buffer / disk space).
>

Sounds like a good idea.

> I need real world reports (like your report)...

I'd appreciate it if my report could help you.
Feel free to let me know if you need more infomation.

Thanks
Yafang