From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751351AbdILUXF (ORCPT ); Tue, 12 Sep 2017 16:23:05 -0400 Received: from mail-pf0-f178.google.com ([209.85.192.178]:33742 "EHLO mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750742AbdILUXD (ORCPT ); Tue, 12 Sep 2017 16:23:03 -0400 X-Google-Smtp-Source: ADKCNb76/r9QjHklEqOzIdMdezmZ5OmwuiLB696vwdTDcM8fsMV0GhuWQivH+AIegIrl1ZzAQK40pA== Date: Tue, 12 Sep 2017 13:23:00 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Roman Gushchin cc: linux-mm@kvack.org, Michal Hocko , 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 3/4] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer In-Reply-To: <20170912200115.GA25218@castle> Message-ID: References: <20170911131742.16482-1-guro@fb.com> <20170911131742.16482-4-guro@fb.com> <20170912200115.GA25218@castle> 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 On Tue, 12 Sep 2017, Roman Gushchin wrote: > > I can't imagine that Tejun would be happy with a new mount option, > > especially when it's not required. > > > > OOM behavior does not need to be defined at mount time and for the entire > > hierarchy. It's possible to very easily implement a tunable as part of > > mem cgroup that is propagated to descendants and controls the oom scoring > > behavior for that hierarchy. It does not need to be system wide and > > affect scoring of all processes based on which mem cgroup they are > > attached to at any given time. > > No, I don't think that mixing per-cgroup and per-process OOM selection > algorithms is a good idea. > > So, there are 3 reasonable options: > 1) boot option > 2) sysctl > 3) cgroup mount option > > I believe, 3) is better, because it allows changing the behavior dynamically, > and explicitly depends on v2 (what sysctl lacks). > > So, the only question is should it be opt-in or opt-out option. > Personally, I would prefer opt-out, but Michal has a very strong opinion here. > If it absolutely must be a mount option, then I would agree it should be opt-in so that it's known what is being changed rather than changing how selection was done in the past and requiring legacy users to now mount in a new way. I'd be interested to hear Tejun's comments, however, about whether we want to add controller specific mount options like this instead of a tunable at the root level, for instance, that controls victim selection and would be isolated to the memory cgroup controller as opposed to polluting mount options.