From: Roman Gushchin <guro@fb.com> To: David Rientjes <rientjes@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>, <cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org> Subject: Re: [patch -mm v3 1/3] mm, memcg: introduce per-memcg oom policy tunable Date: Thu, 15 Mar 2018 17:10:41 +0000 [thread overview] Message-ID: <20180315171039.GB1853@castle.DHCP.thefacebook.com> (raw) In-Reply-To: <alpine.DEB.2.20.1803141341180.163553@chino.kir.corp.google.com> Hello, David! On Wed, Mar 14, 2018 at 01:58:59PM -0700, David Rientjes wrote: > On Wed, 14 Mar 2018, Roman Gushchin wrote: > - Does not lock the entire system into a single methodology. Users > working in a subtree can default to what they are used to: per-process > oom selection even though their subtree might be targeted by a system > policy level decision at the root. This allow them flexibility to > organize their subtree intuitively for use with other controllers in a > single hierarchy. > > The real-world example is a user who currently organizes their subtree > for this purpose and has defined oom_score_adj appropriately and now > regresses if the admin mounts with the needless "groupoom" option. I find this extremely confusing. The problem is that OOM policy defines independently how the OOM of the corresponding scope is handled, not like how it prefers to handle OOMs from above. As I've said, if you're inside a container, you can have OOMs of different types, depending on settings, which you don't even know about. Sometimes oom_score_adj works, sometimes not. Sometimes all processes are killed, sometimes not. IMO, this adds nothing but mess. The mount option (which I'm not a big fan of too) was added only to provide a 100% backward compatibility, what was forced by Michal. But I doubt that mixing per-process and per-cgroup approach makes any sense. > > - Allows changing the oom policy at runtime without remounting the entire > cgroup fs. Depending on how cgroups are going to be used, per-process > vs cgroup-aware may be mandated separately. This is a trait only of > the mem cgroup controller, the root level oom policy is no different > from the subtree and depends directly on how the subtree is organized. > If other controllers are already being used, requiring a remount to > change the system-wide oom policy is an unnecessary burden. > > The real-world example is systems software that either supports user > subtrees or strictly subtrees that it maintains itself. While other > controllers are used, the mem cgroup oom policy can be changed at > runtime rather than requiring a remount and reorganizing other > controllers exactly as before. Btw, what the problem with remounting? You don't have to re-create cgroups, or something like this; the operation is as trivial as adding a flag. > > - Can be extended to cgroup v1 if necessary. There is no need for a > new cgroup v1 mount option and mem cgroup oom selection is not > dependant on any functionality provided by cgroup v2. The policies > introduced here work exactly the same if used with cgroup v1. > > The real-world example is a cgroup configuration that hasn't had > the ability to move to cgroup v2 yet and still would like to use > cgroup-aware oom selection with a very trivial change to add the > memory.oom_policy file to the cgroup v1 filesystem. I assume that v1 interface is frozen. Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro@fb.com> To: David Rientjes <rientjes@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, Vladimir Davydov <vdavydov.dev@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch -mm v3 1/3] mm, memcg: introduce per-memcg oom policy tunable Date: Thu, 15 Mar 2018 17:10:41 +0000 [thread overview] Message-ID: <20180315171039.GB1853@castle.DHCP.thefacebook.com> (raw) In-Reply-To: <alpine.DEB.2.20.1803141341180.163553@chino.kir.corp.google.com> Hello, David! On Wed, Mar 14, 2018 at 01:58:59PM -0700, David Rientjes wrote: > On Wed, 14 Mar 2018, Roman Gushchin wrote: > - Does not lock the entire system into a single methodology. Users > working in a subtree can default to what they are used to: per-process > oom selection even though their subtree might be targeted by a system > policy level decision at the root. This allow them flexibility to > organize their subtree intuitively for use with other controllers in a > single hierarchy. > > The real-world example is a user who currently organizes their subtree > for this purpose and has defined oom_score_adj appropriately and now > regresses if the admin mounts with the needless "groupoom" option. I find this extremely confusing. The problem is that OOM policy defines independently how the OOM of the corresponding scope is handled, not like how it prefers to handle OOMs from above. As I've said, if you're inside a container, you can have OOMs of different types, depending on settings, which you don't even know about. Sometimes oom_score_adj works, sometimes not. Sometimes all processes are killed, sometimes not. IMO, this adds nothing but mess. The mount option (which I'm not a big fan of too) was added only to provide a 100% backward compatibility, what was forced by Michal. But I doubt that mixing per-process and per-cgroup approach makes any sense. > > - Allows changing the oom policy at runtime without remounting the entire > cgroup fs. Depending on how cgroups are going to be used, per-process > vs cgroup-aware may be mandated separately. This is a trait only of > the mem cgroup controller, the root level oom policy is no different > from the subtree and depends directly on how the subtree is organized. > If other controllers are already being used, requiring a remount to > change the system-wide oom policy is an unnecessary burden. > > The real-world example is systems software that either supports user > subtrees or strictly subtrees that it maintains itself. While other > controllers are used, the mem cgroup oom policy can be changed at > runtime rather than requiring a remount and reorganizing other > controllers exactly as before. Btw, what the problem with remounting? You don't have to re-create cgroups, or something like this; the operation is as trivial as adding a flag. > > - Can be extended to cgroup v1 if necessary. There is no need for a > new cgroup v1 mount option and mem cgroup oom selection is not > dependant on any functionality provided by cgroup v2. The policies > introduced here work exactly the same if used with cgroup v1. > > The real-world example is a cgroup configuration that hasn't had > the ability to move to cgroup v2 yet and still would like to use > cgroup-aware oom selection with a very trivial change to add the > memory.oom_policy file to the cgroup v1 filesystem. I assume that v1 interface is frozen. Thanks!
next prev parent reply other threads:[~2018-03-15 17:11 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-13 0:57 [patch -mm v3 0/3] mm, memcg: introduce oom policies David Rientjes 2018-03-13 0:57 ` [patch -mm v3 1/3] mm, memcg: introduce per-memcg oom policy tunable David Rientjes 2018-03-14 12:38 ` Roman Gushchin 2018-03-14 12:38 ` Roman Gushchin 2018-03-14 12:38 ` Roman Gushchin 2018-03-14 20:58 ` David Rientjes 2018-03-15 17:10 ` Roman Gushchin [this message] 2018-03-15 17:10 ` Roman Gushchin 2018-03-15 20:16 ` David Rientjes 2018-03-13 0:57 ` [patch -mm v3 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable David Rientjes 2018-03-13 0:57 ` [patch -mm v3 3/3] mm, memcg: add hierarchical usage oom policy David Rientjes 2018-03-14 0:21 ` [patch -mm] mm, memcg: evaluate root and leaf memcgs fairly on oom David Rientjes 2018-03-14 12:17 ` Roman Gushchin 2018-03-14 12:17 ` Roman Gushchin 2018-03-14 20:41 ` David Rientjes 2018-03-15 16:46 ` Roman Gushchin 2018-03-15 16:46 ` Roman Gushchin 2018-03-15 20:01 ` David Rientjes 2018-03-15 20:34 ` [patch -mm] mm, memcg: separate oom_group from selection criteria David Rientjes 2018-03-15 20:51 ` [patch -mm] mm, memcg: disregard mempolicies for cgroup-aware oom killer David Rientjes 2018-03-15 20:54 ` [patch -mm v3 0/3] mm, memcg: introduce oom policies David Rientjes 2018-03-16 21:08 ` [patch -mm 0/6] rewrite cgroup aware oom killer for general use David Rientjes 2018-03-16 21:08 ` [patch -mm 1/6] mm, memcg: introduce per-memcg oom policy tunable David Rientjes 2018-03-16 21:08 ` [patch -mm 2/6] mm, memcg: replace cgroup aware oom killer mount option with tunable David Rientjes 2018-03-16 21:08 ` [patch -mm 3/6] mm, memcg: add hierarchical usage oom policy David Rientjes 2018-03-16 21:08 ` [patch -mm 4/6] mm, memcg: evaluate root and leaf memcgs fairly on oom David Rientjes 2018-03-18 15:00 ` kbuild test robot 2018-03-18 20:14 ` [patch -mm 4/6 updated] " David Rientjes 2018-03-18 18:18 ` [patch -mm 4/6] " kbuild test robot 2018-03-16 21:08 ` [patch -mm 5/6] mm, memcg: separate oom_group from selection criteria David Rientjes 2018-03-16 21:08 ` [patch -mm 6/6] mm, memcg: disregard mempolicies for cgroup-aware oom killer David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 0/6] rewrite cgroup aware oom killer for general use David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 1/6] mm, memcg: introduce per-memcg oom policy tunable David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 2/6] mm, memcg: replace cgroup aware oom killer mount option with tunable David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 3/6] mm, memcg: add hierarchical usage oom policy David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 4/6] mm, memcg: evaluate root and leaf memcgs fairly on oom David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 5/6] mm, memcg: separate oom_group from selection criteria David Rientjes 2018-03-22 21:53 ` [patch v2 -mm 6/6] mm, memcg: disregard mempolicies for cgroup-aware oom killer David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 0/6] rewrite cgroup aware oom killer for general use David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 1/6] mm, memcg: introduce per-memcg oom policy tunable David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 2/6] mm, memcg: replace cgroup aware oom killer mount option with tunable David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy David Rientjes 2018-07-16 18:16 ` Roman Gushchin 2018-07-16 18:16 ` Roman Gushchin 2018-07-17 4:06 ` David Rientjes 2018-07-23 20:33 ` David Rientjes 2018-07-23 21:28 ` Roman Gushchin 2018-07-23 21:28 ` Roman Gushchin 2018-07-23 23:22 ` David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 4/6] mm, memcg: evaluate root and leaf memcgs fairly on oom David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 5/6] mm, memcg: separate oom_group from selection criteria David Rientjes 2018-07-13 23:07 ` [patch v3 -mm 6/6] mm, memcg: disregard mempolicies for cgroup-aware oom killer David Rientjes
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180315171039.GB1853@castle.DHCP.thefacebook.com \ --to=guro@fb.com \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=rientjes@google.com \ --cc=tj@kernel.org \ --cc=vdavydov.dev@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.