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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>