Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751955AbdIUIat (ORCPT ); Thu, 21 Sep 2017 04:30:49 -0400 Received: from mail-pg0-f51.google.com ([74.125.83.51]:52730 "EHLO mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485AbdIUIar (ORCPT ); Thu, 21 Sep 2017 04:30:47 -0400 X-Google-Smtp-Source: AOwi7QDlHlqfV6gRv6pcTDvLL5lHoltsy7tS6vA8GGHc6YaBzz5ywOSMIZp5h1dATRVDgNVhr/p39A== Date: Thu, 21 Sep 2017 01:30:45 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Roman Gushchin cc: Michal Hocko , linux-mm@kvack.org, Vladimir Davydov , Johannes Weiner , Tetsuo Handa , Andrew Morton , Tejun Heo , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v8 0/4] cgroup-aware OOM killer In-Reply-To: <20170918150254.GA24257@castle.DHCP.thefacebook.com> Message-ID: References: <20170913122914.5gdksbmkolum7ita@dhcp22.suse.cz> <20170913215607.GA19259@castle> <20170914134014.wqemev2kgychv7m5@dhcp22.suse.cz> <20170914160548.GA30441@castle> <20170915105826.hq5afcu2ij7hevb4@dhcp22.suse.cz> <20170915152301.GA29379@castle> <20170915210807.GA5238@castle> <20170918062045.kcfsboxvfmlg2wjo@dhcp22.suse.cz> <20170918150254.GA24257@castle.DHCP.thefacebook.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1005 Lines: 22 On Mon, 18 Sep 2017, Roman Gushchin wrote: > > As said in other email. We can make priorities hierarchical (in the same > > sense as hard limit or others) so that children cannot override their > > parent. > > You mean they can set the knob to any value, but parent's value is enforced, > if it's greater than child's value? > > If so, this sounds logical to me. Then we have size-based comparison and > priority-based comparison with similar rules, and all use cases are covered. > > Ok, can we stick with this design? > Then I'll return oom_priorities in place, and post a (hopefully) final version. > I just want to make sure that we are going with your original implementation here: that oom_priority is only effective for compare sibling memory cgroups and nothing beyond that. The value alone has no relationship to any ancestor. We can't set oom_priority based on the priorities of any other memory cgroups other than our own siblings because we have no control over how those change.