Re: [patch v2 2/2] oom: kill all threads sharing oom killed task's mm

[David Rientjes <rientjes@google.com>]

On Thu, 19 Aug 2010, KOSAKI Motohiro wrote:

> > No, I'm talking about threads with CLONE_VM and not CLONE_THREAD (or 
> > CLONE_VFORK, in your example).  They share the same address space but are 
> > in different tgid's and may sit holding mm->mmap_sem looping in the page 
> > allocator while we know we're oom and there's no chance of freeing any 
> > more memory since the oom killer doesn't kill will other tasks have yet to 
> > exit.
> 
> Why don't you use pthread library? Is there any good reason? That said,
> If you are trying to optimize neither thread nor vfork case, I'm not charmed
> this because 99.99% user don't use it. but even though every user will get 
> performance degression. Can you please consider typical use case optimization?
> 

Non-NPTL threaded applications exist in the wild, and I can't change that.  
This mm->mmap_sem livelock is a problem for them, we've hit it internally 
(we're forced to carry this patch internally), and we aren't the only ones 
running at least some non-NPTL apps.  That's why this code existed in the 
oom killer for over eight years since the 2.4 kernel before you removed it 
based on the mempolicy policy of killing current, which has since been 
obsoleted.  Until CLONE_VM without CLONE_THREAD is prohibited entirely on 
Linux, this livelock can exist.

Users who do not want the tasklist scan here, which only iterates over 
thread group leaders and not threads, can enable 
/proc/sys/vm/oom_kill_allocating_task.  That's its whole purpose.  Other 
than that, the oom killer will never be the most efficient part of the 
kernel and doing for_each_process() is much less expensive than all the 
task_lock()s we take already.

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