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