From: David Rientjes <rientjes@google.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
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
Date: Thu, 25 Jan 2018 15:27:29 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1801251517460.152440@chino.kir.corp.google.com> (raw)
In-Reply-To: <20180125080542.GK28465@dhcp22.suse.cz>
On Thu, 25 Jan 2018, Michal Hocko wrote:
> > As a result, this would remove patch 3/4 from the series. Do you have any
> > other feedback regarding the remainder of this patch series before I
> > rebase it?
>
> Yes, and I have provided it already. What you are proposing is
> incomplete at best and needs much better consideration and much more
> time to settle.
>
Could you elaborate on why specifying the oom policy for the entire
hierarchy as part of the root mem cgroup and also for individual subtrees
is incomplete? It allows admins to specify and delegate policy decisions
to subtrees owners as appropriate. It addresses your concern in the
/admins and /students example. It addresses my concern about evading the
selection criteria simply by creating child cgroups. It appears to be a
win-win. What is incomplete or are you concerned about?
> > I will address the unfair root mem cgroup vs leaf mem cgroup comparison in
> > a separate patchset to fix an issue where any user of oom_score_adj on a
> > system that is not fully containerized gets very unusual, unexpected, and
> > undocumented results.
>
> I will not oppose but as it has been mentioned several times, this is by
> no means a blocker issue. It can be added on top.
>
The current implementation is only useful for fully containerized systems
where no processes are attached to the root mem cgroup. Anything in the
root mem cgroup is judged by different criteria and if they use
/proc/pid/oom_score_adj the entire heuristic breaks down. That's because
per-process usage and oom_score_adj are only relevant for the root mem
cgroup and irrelevant when attached to a leaf. Because of that, users are
affected by the design decision and will organize their hierarchies as
approrpiate to avoid it. Users who only want to use cgroups for a subset
of processes but still treat those processes as indivisible logical units
when attached to cgroups find that it is simply not possible.
I'm focused solely on fixing the three main issues that this
implementation causes. One of them, userspace influence to protect
important cgroups, can be added on top. The other two, evading the
selection criteria and unfair comparison of root vs leaf, are shortcomings
in the design that I believe should be addressed before it's merged to
avoid changing the API later. I'm in no rush to ask for the cgroup aware
oom killer to be merged if it's incomplete and must be changed for
usecases that are not highly specialized (fully containerized and no use
of oom_score_adj for any process). I am actively engaged in fixing it,
however, so that it becomes a candidate for merge. Your feedback is
useful with regard to those fixes, but daily emails on how we must merge
the current implementation now are not providing value, at least to me.
next prev parent reply other threads:[~2018-01-25 23:27 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-17 2:14 [patch -mm 0/4] mm, memcg: introduce oom policies David Rientjes
2018-01-17 2:15 ` [patch -mm 1/4] mm, memcg: introduce per-memcg oom policy tunable David Rientjes
2018-01-17 2:15 ` [patch -mm 2/4] mm, memcg: replace cgroup aware oom killer mount option with tunable David Rientjes
2018-01-17 2:15 ` [patch -mm 3/4] mm, memcg: replace memory.oom_group with policy tunable David Rientjes
2018-01-17 15:41 ` Tejun Heo
2018-01-17 16:00 ` Michal Hocko
2018-01-17 22:18 ` David Rientjes
2018-01-23 15:13 ` Michal Hocko
2018-01-17 22:14 ` David Rientjes
2018-01-19 20:53 ` David Rientjes
2018-01-20 12:32 ` Tejun Heo
2018-01-22 22:34 ` David Rientjes
2018-01-23 15:53 ` Michal Hocko
2018-01-23 22:22 ` David Rientjes
2018-01-24 8:20 ` Michal Hocko
2018-01-24 21:44 ` David Rientjes
2018-01-24 22:08 ` Andrew Morton
2018-01-24 22:18 ` Tejun Heo
2018-01-25 8:11 ` Michal Hocko
2018-01-25 8:05 ` Michal Hocko
2018-01-25 23:27 ` David Rientjes [this message]
2018-01-26 10:07 ` Michal Hocko
2018-01-26 22:33 ` David Rientjes
2018-01-17 2:15 ` [patch -mm 4/4] mm, memcg: add hierarchical usage oom policy David Rientjes
2018-01-17 11:46 ` [patch -mm 0/4] mm, memcg: introduce oom policies Roman Gushchin
2018-01-17 22:31 ` David Rientjes
2018-01-25 23:53 ` [patch -mm v2 0/3] " David Rientjes
2018-01-25 23:53 ` [patch -mm v2 1/3] mm, memcg: introduce per-memcg oom policy tunable David Rientjes
2018-01-26 17:15 ` Michal Hocko
2018-01-29 22:38 ` David Rientjes
2018-01-30 8:50 ` Michal Hocko
2018-01-30 22:38 ` David Rientjes
2018-01-31 9:47 ` Michal Hocko
2018-02-01 10:11 ` David Rientjes
2018-01-25 23:53 ` [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable David Rientjes
2018-01-26 0:00 ` Andrew Morton
2018-01-26 22:20 ` David Rientjes
2018-01-26 22:39 ` Andrew Morton
2018-01-26 22:52 ` David Rientjes
2018-01-27 0:17 ` Andrew Morton
2018-01-29 10:46 ` Michal Hocko
2018-01-29 19:11 ` Tejun Heo
2018-01-30 8:54 ` Michal Hocko
2018-01-30 11:58 ` Roman Gushchin
2018-01-30 12:08 ` Michal Hocko
2018-01-30 12:13 ` Roman Gushchin
2018-01-30 12:20 ` Michal Hocko
2018-01-30 15:15 ` Tejun Heo
2018-01-30 17:30 ` Johannes Weiner
2018-01-30 19:39 ` Andrew Morton
2018-01-29 22:16 ` David Rientjes
2018-01-25 23:53 ` [patch -mm v2 3/3] mm, memcg: add hierarchical usage oom policy 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=alpine.DEB.2.10.1801251517460.152440@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).