[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1801191251080.177541@chino.kir.corp.google.com>
Date: Fri, 19 Jan 2018 12:53:41 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Tejun Heo <tj@...nel.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...nel.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
Johannes Weiner <hannes@...xchg.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
kernel-team@...com, cgroups@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy
tunable
On Wed, 17 Jan 2018, David Rientjes wrote:
> Yes, this is a valid point. The policy of "tree" and "all" are identical
> policies and then the mechanism differs wrt to whether one process is
> killed or all eligible processes are killed, respectively. My motivation
> for this was to avoid having two different tunables, especially because
> later we'll need a way for userspace to influence the decisionmaking to
> protect (bias against) important subtrees. What would really be nice is
> cgroup.subtree_control-type behavior where we could effect a policy and a
> mechanism at the same time. It's not clear how that would be handled to
> allow only one policy and one mechanism, however, in a clean way. The
> simplest for the user would be a new file, to specify the mechanism and
> leave memory.oom_policy alone. Would another file really be warranted?
> Not sure.
>
Hearing no response, I'll implement this as a separate tunable in a v2
series assuming there are no better ideas proposed before next week. One
of the nice things about a separate tunable is that an admin can control
the overall policy and they can delegate the mechanism (killall vs one
process) to a user subtree. I agree with your earlier point that killall
vs one process is a property of the workload and is better defined
separately.
I'll also look to fix the breakage wrt root mem cgroup comparison with
leaf mem cgroup comparison that is currently in -mm.
Powered by blists - more mailing lists