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


> If concurrent OOM on multiple non-overwrapping memcg domains is a real problem,
> killable lock on per-memcg oom_lock will be better than trylock on global oom_lock.

I am wondering why we select the process per memcg, for example,

select_bad_process
    if (is_memcg_oom(oc))
        mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc);
    else
        mem_cgroup_scan_tasks(root_mem_cgorup, oom_evaluate_task, oc);

Then we can put the lock here to lock each memcg, and avoid the oom
contention between different memcgs.

-- 
Thanks
Yafang