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 v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy Date: Mon, 23 Jul 2018 14:28:58 -0700 [thread overview] Message-ID: <20180723212855.GA25062@castle> (raw) In-Reply-To: <alpine.DEB.2.21.1807231331510.105582@chino.kir.corp.google.com> On Mon, Jul 23, 2018 at 01:33:19PM -0700, David Rientjes wrote: > On Mon, 16 Jul 2018, David Rientjes wrote: > > > > And "tree" is different. It actually changes how the selection algorithm works, > > > and sub-tree settings do matter in this case. > > > > > > > "Tree" is considering the entity as a single indivisible memory consumer, > > it is compared with siblings based on its hierarhical usage. It has > > cgroup oom policy. > > > > It would be possible to separate this out, if you'd prefer, to account > > an intermediate cgroup as the largest descendant or the sum of all > > descendants. I hadn't found a usecase for that, however, but it doesn't > > mean there isn't one. If you'd like, I can introduce another tunable. > > > > Roman, I'm trying to make progress so that the cgroup aware oom killer is > in a state that it can be merged. Would you prefer a second tunable here > to specify a cgroup's points includes memory from its subtree? Hi, David! It's hard to tell, because I don't have a clear picture of what you're suggesting now. My biggest concern about your last version was that it's hard to tell what oom_policy really defines. Each value has it's own application rules, which is a bit messy (some values are meaningful for OOMing cgroup only, other are reading on hierarchy traversal). If you know how to make it clear and non-contradictory, please, describe the proposed interface. > > It would be helpful if you would also review the rest of the patchset. I think, that we should focus on interface semantics right now. If we can't agree on how the things should work, it makes no sense to discuss the implementation. 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 v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy Date: Mon, 23 Jul 2018 14:28:58 -0700 [thread overview] Message-ID: <20180723212855.GA25062@castle> (raw) In-Reply-To: <alpine.DEB.2.21.1807231331510.105582@chino.kir.corp.google.com> On Mon, Jul 23, 2018 at 01:33:19PM -0700, David Rientjes wrote: > On Mon, 16 Jul 2018, David Rientjes wrote: > > > > And "tree" is different. It actually changes how the selection algorithm works, > > > and sub-tree settings do matter in this case. > > > > > > > "Tree" is considering the entity as a single indivisible memory consumer, > > it is compared with siblings based on its hierarhical usage. It has > > cgroup oom policy. > > > > It would be possible to separate this out, if you'd prefer, to account > > an intermediate cgroup as the largest descendant or the sum of all > > descendants. I hadn't found a usecase for that, however, but it doesn't > > mean there isn't one. If you'd like, I can introduce another tunable. > > > > Roman, I'm trying to make progress so that the cgroup aware oom killer is > in a state that it can be merged. Would you prefer a second tunable here > to specify a cgroup's points includes memory from its subtree? Hi, David! It's hard to tell, because I don't have a clear picture of what you're suggesting now. My biggest concern about your last version was that it's hard to tell what oom_policy really defines. Each value has it's own application rules, which is a bit messy (some values are meaningful for OOMing cgroup only, other are reading on hierarchy traversal). If you know how to make it clear and non-contradictory, please, describe the proposed interface. > > It would be helpful if you would also review the rest of the patchset. I think, that we should focus on interface semantics right now. If we can't agree on how the things should work, it makes no sense to discuss the implementation. Thanks!
next prev parent reply other threads:[~2018-07-23 21:29 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 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 [this message] 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=20180723212855.GA25062@castle \ --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.