On Fri, Aug 07, 2015 at 08:17:23PM +0200, Michal Hocko wrote: > On Thu 06-08-15 11:30:08, KAMEZAWA Hiroyuki wrote: > > - *.oom_control - for surviving/notifiyng out of memory > > memcg's oom can be recovered if limit goes up rather than kill. > > I think it is very much useful - when used wisely. I have seen many > calls for user defined OOM policies but then we have seen those that are > more creative like having the policy maker live in the same memcg which > requires some hacks to prevent from self-deadlocks. > So overall this is very attractive but we might need to think about a > better interface. BPF sounds like a potential way to go. I feel the > memcg and the global approaches should be consistent as much as possible > wrt. API. I'm not sure I still see a usecase for this. The whole idea behind memory.high is to give the user the chance to monitor the group's health and then act upon that. You can freeze the group if you must, gather information, kill tasks. This is the way to implement a custom OOM policy. memory.max on the other hand tells the *kernel* when to OOM, with all the implications that a kernel OOM has. Don't configure that when you don't want your tasks killed. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
