On Wed, 22 Dec 2010, KAMEZAWA Hiroyuki wrote: > > > seems to be hard to use. No one can estimate "milisecond" for avoidling > > > OOM-kill. I think this is very bad. Nack to this feature itself. > > > > > > > There's no estimation that is really needed, we simply need to be able to > > stall long enough that we'll eventually kill "something" if userspace > > fails to act. > > > > Why we have to think of usermode failure by mis configuration or user mode bug ? > It's a work of Middleware in usual. > Please make libcgroup or libvirt more useful. > It's a general concern for users who wish to defer the kernel oom killer unless userspace chooses not to act or cannot act and the only way to do that without memory.oom_delay is to set all memcgs to have memory.oom_control of 1. memory.oom_control of 1 is equivalent to OOM_DISABLE for all attached tasks and if all tasks are assigned non-root memcg for resource isolation (and the sum of those memcgs' limits equals system RAM), we always get memcg oom kills instead of system wide oom kills. The difference in this case is that with the memcg oom kills, the kernel livelocks whereas the system wide oom kills would panic the machine since all eligible tasks are OOM_DISABLE, the equivalent of all memcgs having memory.oom_control of 1. Since the kernel has opened this possibility up by disabling oom killing without giving userspace any other chance of deferring the oom killer, we need a way to preserve the machine by having a fallback plan if userspace cannot act. The other possibility would be to panic if all memcgs have memory.oom_control of 1 and the sum of their limits equals the machine's memory capacity. -- 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 policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>