On Sat 28-05-16 21:22:08, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Michal Hocko wrote: > > > We could very well do > > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > > > index bcb6d3b26c94..d9017b8c7300 100644 > > > --- a/mm/oom_kill.c > > > +++ b/mm/oom_kill.c > > > @@ -813,6 +813,7 @@ void oom_kill_process(struct oom_control *oc, struct task_struct *p, > > > * memory might be still used. > > > */ > > > can_oom_reap = false; > > > + set_bit(MMF_OOM_REAPED, mm->flags); > > > continue; > > > } > > > if (p->signal->oom_score_adj == OOM_ADJUST_MIN) > > > > > > with the same result. If you _really_ think that this would make a > > > difference I could live with that. But I am highly skeptical this > > > matters all that much. > > Usage of set_bit() above and below are both wrong. The mm used by > kernel thread via use_mm() will become OOM reapable after unuse_mm(). Please note that all other holders of that mm are gone by that time. So unuse_mm will simply drop the last reference of the mm and do the remaining clean up. There is no real reason this mm should be around and visible by the oom killer. -- 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>