On Tue, 2 Feb 2016, Tetsuo Handa wrote: > Maybe we all agree with introducing OOM reaper without queuing, but I do > want to see a guarantee for scheduling for next OOM-kill operation before > trying to build a reliable queuing chain. > The race can be fixed in two ways which I've already enumerated, but the scheduling issue is tangential: the oom_reaper kthread is going to run; increasing it's priority will only interfere with other innocent processes that are not attached to the oom memcg hierarchy, have disjoint cpuset mems, or are happily allocating from mempolicy nodes with free memory. -- 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>