Messages in this thread | | | Date | Fri, 19 Jan 2018 12:53:41 -0800 (PST) | From | David Rientjes <> | 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.
| |