From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753983AbeAQWSi (ORCPT ); Wed, 17 Jan 2018 17:18:38 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:39467 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752306AbeAQWSf (ORCPT ); Wed, 17 Jan 2018 17:18:35 -0500 X-Google-Smtp-Source: ACJfBotz3dq1b20Oemhhh3rLxErw0qfCmA9B9xew8orlHJYYZln/crxCmWMhsrsP5Kg00Sp16DM1WQ== Date: Wed, 17 Jan 2018 14:18:33 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: Tejun Heo , Andrew Morton , Roman Gushchin , 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: <20180117160004.GH2900@dhcp22.suse.cz> Message-ID: References: <20180117154155.GU3460072@devbig577.frc2.facebook.com> <20180117160004.GH2900@dhcp22.suse.cz> 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, Michal Hocko wrote: > Absolutely agreed! And moreover, there are not all that many ways what > to do as an action. You just kill a logical entity - be it a process or > a logical group of processes. But you have way too many policies how > to select that entity. Do you want to chose the youngest process/group > because all the older ones have been computing real stuff and you would > lose days of your cpu time? Or should those who pay more should be > protected (aka give them static priorities), or you name it... > That's an argument for making the interface extensible, yes. > I am sorry, I still didn't grasp the full semantic of the proposed > soluton but the mere fact it is starting by conflating selection and the > action is a no go and a wrong API. This is why I've said that what you > (David) outlined yesterday is probably going to suffer from a much > longer discussion and most likely to be not acceptable. Your patchset > proves me correct... I'm very happy to change the API if there are better suggestions. That may end up just being an memory.oom_policy file, as this implements, and separating out a new memory.oom_action that isn't a boolean value to either do a full group kill or only a single process. Or it could be what I suggested in my mail to Tejun, such as "hierarchy killall" written to memory.oom_policy, which would specify a single policy and then an optional mechanism. With my proposed patchset, there would then be three policies: "none", "cgroup", and "tree" and one possible optional mechanism: "killall". 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: Wed, 17 Jan 2018 14:18:33 -0800 (PST) Message-ID: References: <20180117154155.GU3460072@devbig577.frc2.facebook.com> <20180117160004.GH2900@dhcp22.suse.cz> 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=1xu2uHkFKAmEO6Vq8yHfLTa3gqLWd/JCI0iEM8/yBVY=; b=dmYbZK20s17u3VGwKiUGyxWSpudirGTC4sVVhMfeDhArZgVVijBnYtngpcYq2s7nLb xTPE18QoRSA7xWX5lOnvcELZSjIo+e3z4FEfTuuPA5qT1Waa1tAwFPWBpDZqXgU8if3o OEmKjEZVce0G3nRmJeklwdMHI5HmKHADJeU6xnzSOqT8RBYbAjBZlUJKWPqAnb4+adfg GuHXfZgfOdtEeEDsDJ8CDKH/YaU0rUDToEWbec33eqTmyQaCMNwAC0pctpEctNbAKMWu 3yB0732pTxDFjQL/AqvDHP1Upy4lspE6JkEe7ETcsZkD6yMWX8UCMaEQiL5Z0UkYYZsH dZrQ== In-Reply-To: <20180117160004.GH2900@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: Tejun Heo , Andrew Morton , Roman Gushchin , 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, Michal Hocko wrote: > Absolutely agreed! And moreover, there are not all that many ways what > to do as an action. You just kill a logical entity - be it a process or > a logical group of processes. But you have way too many policies how > to select that entity. Do you want to chose the youngest process/group > because all the older ones have been computing real stuff and you would > lose days of your cpu time? Or should those who pay more should be > protected (aka give them static priorities), or you name it... > That's an argument for making the interface extensible, yes. > I am sorry, I still didn't grasp the full semantic of the proposed > soluton but the mere fact it is starting by conflating selection and the > action is a no go and a wrong API. This is why I've said that what you > (David) outlined yesterday is probably going to suffer from a much > longer discussion and most likely to be not acceptable. Your patchset > proves me correct... I'm very happy to change the API if there are better suggestions. That may end up just being an memory.oom_policy file, as this implements, and separating out a new memory.oom_action that isn't a boolean value to either do a full group kill or only a single process. Or it could be what I suggested in my mail to Tejun, such as "hierarchy killall" written to memory.oom_policy, which would specify a single policy and then an optional mechanism. With my proposed patchset, there would then be three policies: "none", "cgroup", and "tree" and one possible optional mechanism: "killall". -- 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