On Mon, 7 Mar 2011 21:30:19 -0800 (PST)
David Rientjes [off-list ref] wrote:

On Tue, 8 Mar 2011, KAMEZAWA Hiroyuki wrote:

quoted

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@kvack.org.  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@kvack.org"> email@kvack.org </a>