On Mon, 7 Mar 2011 17:33:44 -0800 (PST) David Rientjes <rientjes@xxxxxxxxxx> wrote: > On Mon, 7 Mar 2011, Andrew Morton wrote: > > > > 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@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>