On Mon, 7 Mar 2011 21:30:19 -0800 (PST) David Rientjes <rientjes@xxxxxxxxxx> wrote: > 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. > That sounds like a mis-usage problem....what kind of workaround is offerred if the user doesn't configure oom_delay_millisecs , a yet another mis-usage ? THanks, -Kame -- 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>