On Tue, 16 Feb 2010, KAMEZAWA Hiroyuki wrote: > > If /proc/sys/vm/panic_on_oom is set to 2, the kernel will panic > > regardless of whether the memory allocation is constrained by either a > > mempolicy or cpuset. > > > > Since mempolicy-constrained out of memory conditions now iterate through > > the tasklist and select a task to kill, it is possible to panic the > > machine if all tasks sharing the same mempolicy nodes (including those > > with default policy, they may allocate anywhere) or cpuset mems have > > /proc/pid/oom_adj values of OOM_DISABLE. This is functionally equivalent > > to the compulsory panic_on_oom setting of 2, so the mode is removed. > > > > Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx> > > NACK. In an enviroment which depends on cluster-fail-over, this is useful > even if in such situation. > You don't understand that the behavior has changed ever since mempolicy-constrained oom conditions are now affected by a compulsory panic_on_oom mode, please see the patch description. It's absolutely insane for a single sysctl mode to panic the machine anytime a cpuset or mempolicy runs out of memory and is more prone to user error from setting it without fully understanding the ramifications than any use it will ever do. The kernel already provides a mechanism for doing this, OOM_DISABLE. if you want your cpuset or mempolicy to risk panicking the machine, set all tasks that share its mems or nodes, respectively, to OOM_DISABLE. This is no different from the memory controller being immune to such panic_on_oom conditions, stop believing that it is the only mechanism used in the kernel to do memory isolation. -- 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>