Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751854AbbHQWFf (ORCPT ); Mon, 17 Aug 2015 18:05:35 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:49883 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751053AbbHQWFd (ORCPT ); Mon, 17 Aug 2015 18:05:33 -0400 Date: Tue, 18 Aug 2015 00:04:48 +0200 From: Johannes Weiner To: Michal Hocko Cc: Kamezawa Hiroyuki , Tejun Heo , mingo@redhat.com, peterz@infradead.org, lizefan@huawei.com, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 1/3] cgroup: define controller file conventions Message-ID: <20150817220448.GC29138@cmpxchg.org> References: <1438641689-14655-1-git-send-email-tj@kernel.org> <1438641689-14655-2-git-send-email-tj@kernel.org> <20150804193101.GI17598@mtj.duckdns.org> <55C15B4C.9080202@jp.fujitsu.com> <20150805074758.GA11182@dhcp22.suse.cz> <55C2C6B0.3080203@jp.fujitsu.com> <20150807181722.GA24877@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150807181722.GA24877@dhcp22.suse.cz> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1480 Lines: 29 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/