On Mon, 7 Mar 2011 17:33:44 -0800 (PST)
David Rientjes [off-list ref] wrote:

On Mon, 7 Mar 2011, Andrew Morton wrote:

quoted

quoted

It could be, if users assign the handler to a different memcg; otherwise, 
it's guaranteed.

Putting the handler into the same container would be rather daft.

If userspace is going to elect to take over a kernel function then it
should be able to perform that function reliably.  We don't have hacks
in the kernel to stop runaway SCHED_FIFO tasks, either.  If the oom
handler has put itself into a memcg and then has permitted that memcg
to go oom then userspace is busted.

We have a container specifically for daemons like this and have struggled 
for years to accurately predict how much memory it needs and what to do 
when it is oom.  The problem, in this case, is that when it's oom it's too 
late: the memcg is livelocked and then no memory limits on the system have 
a chance of getting increased and nothing in oom memcgs are guaranteed to 
ever make forward progress again.

That's why I keep bringing up the point that this patch is not a bugfix: 
it's an extension of a feature (memory.oom_control) to allow userspace a 
period of time to respond to memcgs reaching their hard limit before 
killing something.  For our container with vital system daemons, this is 
absolutely mandatory if something consumes a large amount of memory and 
needs to be restarted; we want the logic in userspace to determine what to 
do without killing vital tasks or panicking.  We want to use the oom 
killer only as a last resort and that can effectively be done with this 
patch and not with memory.oom_control (and I think this is why Kame acked 
it).

I acked just because the code itself seems to work. _And_ I can't convince
you "that function is never necessary". But please note, you don't convice
me "that's necessary".

BTW, why "the memcg is livelocked and then no memory limits on the system have 
a chance of getting increased"

Is there a memcg bug which prevents increasing limit ?

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>