Re: [patch v2] mm, oom: do not schedule if current has been killed

[David Rientjes <rientjes@google.com>]

On Tue, 19 Jun 2012, KOSAKI Motohiro wrote:

> > The killed process may exit but it does not guarantee that its memory will 
> > be freed if it's shared with current.  This is the case that the patch is 
> > addressing, where right now we unnecessarily schedule if current has been 
> > killed or is already along the exit path.  We want to retry as soon as 
> > possible so that either the allocation now succeeds or we can recall the 
> > oom killer as soon as possible and get TIF_MEMDIE set because we have a 
> > fatal signal so current may exit in a timely way as well.  The point is 
> > that if current has either a SIGKILL or is already exiting as it returns 
> > from the oom killer, it does no good to continue to stall and prevent that 
> > memory freeing.
> 
> You missed live lock risk. immediate retry makes immediate fail if no one
> freed any memory. Even if the task call out_of_memory() again, select_bad_process()
> may return -1 and don't makes any forward progress.
> 

I missed a livelock?  You missed the fact that the oom killer is 
short-circuited by this before anything else gets done:

	if (fatal_signal_pending(current)) {
		set_thread_flag(TIF_MEMDIE);
		return;
	}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>