Re: [PATCH] mm, oom: OOM victims do not need to select next OOM victim unless __GFP_NOFAIL.

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

On 2018/08/28 22:51, Michal Hocko wrote:
> On Tue 28-08-18 22:29:56, Tetsuo Handa wrote:
> [...]
>> The OOM reaper may set MMF_OOM_SKIP without reclaiming any memory (due
>> to e.g. mlock()ed memory, shared memory, unable to grab mmap_sem for read).
>> We haven't reached to the point where the OOM reaper reclaims all memory
>> nor allocating threads wait some more after setting MMF_OOM_SKIP.
>> Therefore, this
>>
>>   if (tsk_is_oom_victim(current) && !(oc->gfp_mask & __GFP_NOFAIL))
>>       return true;
>>
>> is the simplest mitigation we can do now.
> 
> But this is adding a mess because you pretend to make a forward progress
> even the OOM path didn't do anything at all and rely on another kludge
> elsewhere to work.

I'm not pretending to make a forward progress. If current thread is an OOM
victim, it is guaranteed to make forward progress (unless __GFP_NOFAIL) by
failing that allocation attempt after trying memory reserves. The OOM path
does not need to do anything at all.