From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756549AbeASUxw (ORCPT ); Fri, 19 Jan 2018 15:53:52 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:41048 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756492AbeASUxo (ORCPT ); Fri, 19 Jan 2018 15:53:44 -0500 X-Google-Smtp-Source: ACJfBos5QV8b2KWW5X57Z+71SxSVXpEAyLOiBT2Lszeq8trf4Kaw0hBNbRZA+5U0OZS6ChZ3hubmWQ== Date: Fri, 19 Jan 2018 12:53:41 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com 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 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> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Rientjes Subject: Re: [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable Date: Fri, 19 Jan 2018 12:53:41 -0800 (PST) Message-ID: References: <20180117154155.GU3460072@devbig577.frc2.facebook.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=HDpKV/02DbdHINZc7lYlYzyOOpGrMBTdpR4DhPZn1pM=; b=bzodQpUdPQi05drILoGzQJxiGVyiipeYfzLCZPKvv8rwDMslcPNI+Cr6zcLirLJMPE pKaVWhca8WcfEVf/M3Q8gTNzmS2gU4J7c8NumHyYKzlitiyB/cYqDFe1+URnXB97aaod OYgAZXpknrJSWGYavbSlSShytm98kWee4JzucUWOO8HqpOm4ixl358nGjg1/QOqTQ7JN 2/RQ48wy8/nHz7T4FH9WHR44MjBwodpxnj9qQWSbKWP12cKUxA4Rg3EWr8O7/Yl0k1jZ atJ6Fg/MmheQxCxyf7cgXkt/d5VZ9lnhTiPZcilwF9VlzZ+00mL0VVRW0vmPIZR7p4u/ m9lg== In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit 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