From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) by kanga.kvack.org (Postfix) with ESMTP id D193D6B0033 for ; Fri, 19 Jan 2018 15:53:45 -0500 (EST) Received: by mail-it0-f72.google.com with SMTP id y200so2983808itc.7 for ; Fri, 19 Jan 2018 12:53:45 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id q39sor5649532ioi.274.2018.01.19.12.53.43 for (Google Transport Security); Fri, 19 Jan 2018 12:53:44 -0800 (PST) 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 In-Reply-To: Message-ID: References: <20180117154155.GU3460072@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: Andrew Morton , Roman Gushchin , Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org 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