On Sat, 12 Mar 2011, Oleg Nesterov wrote: > > It's a problem, but not because of > > oom-prevent-unnecessary-oom-kills-or-kernel-panics.patch. > > It is, afaics. oom-killer can't ussume that a single PF_EXITING && p->mm > thread is going to free the memory. > We can add a check to see if a PF_EXITING thread will stall in the exit path as in your testcase, we do not need to filter threads that are still running that results in panics if nothing else is eligible in cpusets. > > but its other threads do not and they trigger oom kills > > themselves. for_each_process() does not iterate over these threads and so > > it finds no eligible threads to kill and then panics > > Could you explain what do you mean? No need to kill these threads, they > are already killed, we should wait until they all exit. > Yes, and the check for PF_EXITING is intended to do exactly that (and give the thread access to memory reserves if it is trying to allocate memory itself). The problem with your testcase is that the thread will indefinitely stall, so the appropriate fix is to detect that possibility and avoid the deferral if its possible. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>