Michal Hocko wrote: > > https://lkml.org/lkml/2015/3/25/40 > > > > We could have out_of_memory() wait until the number of outstanding OOM > > victims drops to 0. Then __alloc_pages_may_oom() doesn't relinquish > > the lock until its kill has been finalized: > > > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > > index 914451a..4dc5b9d 100644 > > --- a/mm/oom_kill.c > > +++ b/mm/oom_kill.c > > @@ -892,7 +892,9 @@ bool out_of_memory(struct oom_control *oc) > > * Give the killed process a good chance to exit before trying > > * to allocate memory again. > > */ > > - schedule_timeout_killable(1); > > + if (!test_thread_flag(TIF_MEMDIE)) > > + wait_event_timeout(oom_victims_wait, > > + !atomic_read(&oom_victims), HZ); > > } > > return true; > > } > > Yes this makes sense to me I think schedule_timeout_killable(1) was used for handling cases where current thread did not get TIF_MEMDIE but got SIGKILL due to sharing the victim's memory. If current thread is blocking TIF_MEMDIE thread, this can become a needless delay. Also, I don't know whether using wait_event_*() helps handling a problem that schedule_timeout_killable(1) can sleep for many minutes with oom_lock held when there are a lot of tasks. Detail is explained in my proposed patch. -- 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>