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

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

On 6/19/2012 2:59 PM, David Rientjes wrote:
> 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;
> 	}
> 

I talked about PF_EXITING. fatal signal is no problem.


--
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>