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