On Wed, 3 Mar 2010, KAMEZAWA Hiroyuki wrote: > > Trying to set ZONE_OOM_LOCKED for all populated zones is fundamentally the > > correct thing to do on VM_FAULT_OOM when you don't know the context in > > which we're trying to allocate pages. The _only_ thing that does is close > > a race between when another thread calls out_of_memory(), which is likely > > in such conditions, and the oom killer hasn't killed a task yet so we > > can't detect the TIF_MEMDIE bit during the tasklist scan. Memcg is > > completely irrelevant with respect to this zone locking and that's why I > > didn't touch mem_cgroup_out_of_memory(). Did you seriously even read this > > patch? > > > > Then, memcg will see second oom-kill. > Sigh. Memcg will only kill a second task if the parallel oom hasn't killed anything yet or the parallel oom kills a task that is not in the memcg, and that's because memcg needs to enforce its limit by killing something, freeing memory for the system won't help that. We may kill another task for the system-wide oom after the memcg has already killed a task if the system-wide oom is iterating through the tasklist and the memcg kill sets TIF_MEMDIE too late. That's independent of this patch, we can't go and recind an oom kill. Labeling that as a regression is just not truthful, it's outside the scope of closing the VM_FAULT_OOM race. -- 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>