Michal Hocko wrote: > On Thu 14-04-16 19:56:30, Tetsuo Handa wrote: > > Assuming that try_oom_reaper() is correctly implemented, we should use > > try_oom_reaper() for testing "whether the OOM reaper is allowed to reap > > the OOM victim's memory" rather than "whether the OOM killer is allowed > > to send SIGKILL to thread groups sharing the OOM victim's memory", > > for the OOM reaper is allowed to reap the OOM victim's memory even if > > that memory is shared by OOM_SCORE_ADJ_MIN but already-killed-or-exiting > > thread groups. > > So you prefer to crawl over the whole task list again just to catch a > really unlikely case where the OOM_SCORE_ADJ_MIN mm sharing task was > already exiting? Under which workload does this matter? > > The patch seems correct I just do not see any point in it because I do > not think it handles any real life situation. I basically consider any > workload where only _certain_ thread(s) or process(es) sharing the mm have > OOM_SCORE_ADJ_MIN set as invalid. Why should we care about those? This > requires root to cripple the system. Or am I missing a valid > configuration where this would make any sense? Because __oom_reap_task() as of current linux.git marks only one of thread groups as OOM_SCORE_ADJ_MIN and happily disables further reaping (which I'm utilizing such behavior for catching bugs which occur under almost OOM situation). -- 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>