Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable

David Rientjes
2018-01-19T20:53:41Z

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: email@kvack.org