On 2018/08/08 5:38, Tetsuo Handa wrote: > On 2018/08/08 5:19, Johannes Weiner wrote: >> On Tue, Aug 07, 2018 at 07:15:11PM +0900, Tetsuo Handa wrote: >>> On 2018/08/07 16:25, Michal Hocko wrote: >>>> @@ -1703,7 +1703,8 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int >>>> return OOM_ASYNC; >>>> } >>>> >>>> - if (mem_cgroup_out_of_memory(memcg, mask, order)) >>>> + if (mem_cgroup_out_of_memory(memcg, mask, order) || >>>> + tsk_is_oom_victim(current)) >>>> return OOM_SUCCESS; >>>> >>>> WARN(1,"Memory cgroup charge failed because of no reclaimable memory! " >>>> >>> >>> I don't think this patch is appropriate. This patch only avoids hitting WARN(1). >>> This patch does not address the root cause: >>> >>> The task_will_free_mem(current) test in out_of_memory() is returning false >>> because test_bit(MMF_OOM_SKIP, &mm->flags) test in task_will_free_mem() is >>> returning false because MMF_OOM_SKIP was already set by the OOM reaper. The OOM >>> killer does not need to start selecting next OOM victim until "current thread >>> completes __mmput()" or "it fails to complete __mmput() within reasonable >>> period". >> >> I don't see why it matters whether the OOM victim exits or not, unless >> you count the memory consumed by struct task_struct. > > We are not counting memory consumed by struct task_struct. But David is > counting memory released between set_bit(MMF_OOM_SKIP, &mm->flags) and > completion of exit_mmap(). Also, before the OOM reaper was introduced, we waited until TIF_MEMDIE is cleared from the OOM victim thread. Compared to pre OOM reaper era, giving up so early is certainly a regression.
