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

[Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>]

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

>         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