On Tue, 8 Mar 2011, KAMEZAWA Hiroyuki wrote: > Hmm? That's an unexpected answer. Why system's capacity is problem here ? > (root memcg has no 'limit' always.) > > Is it a problem that 'there is no 'guarantee' or 'private page pool' > for daemons ? > It's not an inherent problem of memcg, it's a configuration issue: if your userspace application cannot respond to address an oom condition in a memcg for whatever reason (such as it being in an oom memcg itself), then there's a chance that the memcg will livelock since the kernel cannot do anything to fix the issue itself. That's aside from the general purpose of the new memory.oom_delay_millisecs: users may want a grace period for userspace to increase the hard limit or kill a task before deferring to the kernel. That seems exponentially more useful than simply disabling the oom killer entirely with memory.oom_control. I think it's unfortunate memory.oom_control was merged frst and seems to have tainted this entire discussion. -- 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>