On Wed, 9 Mar 2011, KAMEZAWA Hiroyuki wrote: > > 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. > > > > Why memcg's oom and system's oom happens at the same time ? > Again, I'm not sure what you mean: there's no system oom in what I describe above. I'm saying that userspace may not have sufficient time to react to an oom notification unless the oom killer is disabled via memory.oom_control and re-enabled iff userspace chooses to defer to the kernel. > > 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. > > > > Please add 'notifier' in kernel space and handle the event by kernel module. > It is much better than 'timeout and allow oom-kill again'. > A kernel-space notifier would certainly be helpful, but at what point does the kernel choose to oom kill something? If there's an oom notifier in place, do we always defer killing or for a set period of time? If it's the latter then we'll still want the timeout, otherwise there's no way to guarantee we haven't killed something by the time userspace has a chance to react to the notification. -- 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>