On Sat 20-02-16 01:01:36, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Fri 19-02-16 23:33:31, Tetsuo Handa wrote: > > > Currently, oom_unkillable_task() is called for twice for each thread, > > > once at oom_scan_process_thread() and again at oom_badness(). > > > > > > The reason oom_scan_process_thread() needs to call oom_unkillable_task() > > > is to skip TIF_MEMDIE test and oom_task_origin() test if that thread is > > > not OOM-killable. > > > > > > But there is a problem with this ordering, for oom_task_origin() == true > > > will unconditionally select that thread regardless of oom_score_adj. > > > When we merge the OOM reaper, the OOM reaper will mark already reaped > > > process as OOM-unkillable by updating oom_score_adj. In order to avoid > > > falling into infinite loop, oom_score_adj needs to be checked before > > > doing oom_task_origin() test. > > > > What would be the infinite loop? > > Sequence until we merge the OOM reaper: > > (1) select_bad_process() returns p due to oom_task_origin(p) == true. > (2) oom_kill_process() sends SIGKILL to p and sets TIF_MEMDIE on p. > (3) p gets stuck at down_read(&mm->mmap_sem) in exit_mm(). How would this happen? oom_task_origin is swapoff resp run_store (which triggers KSM). While theoretically both can be done from multithreaded process, does this happen in reality? I seriously doubt so. Doing many changes in an already complex code for non-realistic cases sounds like a bad idea to me. -- Michal Hocko SUSE Labs -- 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>