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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
