Re: [PATCH v2] memcg, oom: check memcg margin for parallel oom

[Michal Hocko <mhocko@kernel.org>]

On Thu 16-07-20 14:54:01, Tetsuo Handa wrote:
> On 2020/07/16 2:30, David Rientjes wrote:
> > But regardless of whether we present previous data to the user in the 
> > kernel log or not, we've determined that oom killing a process is a 
> > serious matter and go to any lengths possible to avoid having to do it.  
> > For us, that means waiting until the "point of no return" to either go 
> > ahead with oom killing a process or aborting and retrying the charge.
> > 
> > I don't think moving the mem_cgroup_margin() check to out_of_memory() 
> > right before printing the oom info and killing the process is a very 
> > invasive patch.  Any strong preference against doing it that way?  I think 
> > moving the check as late as possible to save a process from being killed 
> > when racing with an exiter or killed process (including perhaps current) 
> > has a pretty clear motivation.
> > 
> 
> How about ignoring MMF_OOM_SKIP for once? I think this has almost same
> effect as moving the mem_cgroup_margin() check to out_of_memory() 
> right before printing the oom info and killing the process.

How would that help with races when a task is exiting while the oom
selects a victim? We are not talking about races with the oom_reaper
IIUC. Btw. if races with the oom_reaper are a concern then I would much
rather delay the wake up than complicate the existing protocol even
further.
-- 
Michal Hocko
SUSE Labs