Re: [PATCH] mm, oom: don't invoke oom killer if current has been reapered

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

On Tue, Jul 14, 2020 at 12:06 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2020/07/14 11:58, Yafang Shao wrote:
> > On Tue, Jul 14, 2020 at 10:42 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >>
> >> On 2020/07/14 11:13, Yafang Shao wrote:
> >>> But it seems the proposal that using trylock in
> >>> mem_cgroup_out_of_memory() should  be better?
> >>> The trylock could also solve the problem that different processes are
> >>> doing oom at the same time.
> >>
> >> I think trylock is worse. The trylock needlessly wastes CPU time which could
> >> have been utilized by the OOM killer/reaper for reclaiming memory.
> >
> > If it may wastes the CPU time, we can shed it out for 1 second like
> > what it does in __alloc_pages_may_oom():
> >
> > __alloc_pages_may_oom
> >     if (!mutex_trylock(&oom_lock)) {
> >         schedule_timeout_uninterruptible(1);  // to avoid wasting CPU time
>
> 1 second is HZ. 1 means 1 millisecond if CONFIG_HZ=1000. :-)
>

Right. Thanks for pointing it out :)

> >         return;
> >     }
> >
> > But I find that we doesn't sched it out in pagefault path,
> >
> > pagefault_out_of_memory
> >     if (!mutex_trylock(&oom_lock))
> >         return;
> >
> > I haven't thought deeply what the difference is ...
>
> David Rientjes is proposing it for avoiding soft lockup, and Michal Hocko is refusing it.
> How to give the OOM killer/reaper enough CPU time for reclaiming memory is a dogfight. :-(
>
> https://lkml.kernel.org/r/alpine.DEB.2.21.2003181458100.70237@chino.kir.corp.google.com

OK. I will take a look at the discussion in that thread.

-- 
Thanks
Yafang