On 2016/9/18 14:13, Tetsuo Handa wrote: > Tetsuo Handa wrote: >> As of 4.8-rc6, the OOM reaper cannot take mmap_sem for read at __oom_reap_task() >> because of TIF_MEMDIE thread waiting at ksm_exit() from __mmput() from mmput() >> from exit_mm() from do_exit(). Thus, __oom_reap_task() returns false and >> oom_reap_task() will emit "oom_reaper: unable to reap pid:%d (%s)\n" message. >> Then, oom_reap_task() clears TIF_MEMDIE from that thread, which in turn >> makes oom_scan_process_thread() not to return OOM_SCAN_ABORT because >> atomic_read(&task->signal->oom_victims) becomes 0 due to exit_oom_victim() >> by the OOM reaper. Then, the OOM killer selects next OOM victim because >> ksmd is waking up the OOM killer via a __GFP_FS allocation request. hi, Tetsuo OOM reaper indeed relieve the issue, as had discussed with Michal, but it is not completely solved. and OOM livelock had been solved by backport the patch from Michal. The key is that ksmd enter into the OOM and bail out quickly. because other process implement a OOM in the same zone. therefore, ksmd can not obtain the memory. Thanks zhongjiang > Oops. As of 4.8-rc6, __oom_reap_task() returns true because of > find_lock_task_mm() returning NULL. Thus, oom_reap_task() clears TIF_MEMDIE > without emitting "oom_reaper: unable to reap pid:%d (%s)\n" message. > >> Thus, this bug will be completely solved (at the cost of selecting next >> OOM victim) as of 4.8-rc6. > The conclusion is same. > > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>