Re: [patch] memcg: add oom killer delay

[David Rientjes <rientjes@google.com>]

On Tue, 8 Mar 2011, KAMEZAWA Hiroyuki wrote:

> > 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 ?
> 

Not exactly sure what you mean, but you're saying disabling the oom killer 
with memory.oom_control is not the recommended way to allow userspace to 
fix the issue itself?  That seems like it's the entire usecase: we'd 
rarely want to let a memcg stall when it needs memory without trying to 
address the problem (elevating the limit, killing a lower priority job, 
sending a signal to free memory).  We have a memcg oom notifier to handle 
the situation but there's no guarantee that the kernel won't kill 
something first and that's a bad result if we chose to address it with one 
of the ways mentioned above.

To answer your question: if the admin doesn't configure a 
memory.oom_delay_millisecs, then the oom killer will obviously kill 
something off (if memory.oom_control is also not set) when reclaim fails 
to free memory just as before.

Aside from my specific usecase for this tunable, let me pose a question: 
do you believe that the memory controller would benefit from allowing 
users to have a grace period in which to take one of the actions listed 
above instead of killing something itself?  Yes, this would be possible by 
setting and then unsetting memory.oom_control, but that requires userspace 
to always be responsive (which, at our scale, we can unequivocally say 
isn't always possible) and doesn't effectively deal with spikes in memory 
that may only be temporary and doesn't require any intervention of the 
user at all.

--
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>