From: David Rientjes <rientjes@google.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Michal Hocko <mhocko@suse.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Tejun Heo <tj@kernel.org>,
kernel-team@fb.com, cgroups@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Roman Gushchin <guro@fb.com>
Subject: Re: [RESEND v12 0/6] cgroup-aware OOM killer
Date: Thu, 26 Oct 2017 14:03:41 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1710261359550.75887@chino.kir.corp.google.com> (raw)
In-Reply-To: <20171026142445.GA21147@cmpxchg.org>
On Thu, 26 Oct 2017, Johannes Weiner wrote:
> > The nack is for three reasons:
> >
> > (1) unfair comparison of root mem cgroup usage to bias against that mem
> > cgroup from oom kill in system oom conditions,
> >
> > (2) the ability of users to completely evade the oom killer by attaching
> > all processes to child cgroups either purposefully or unpurposefully,
> > and
> >
> > (3) the inability of userspace to effectively control oom victim
> > selection.
>
> My apologies if my summary was too reductionist.
>
> That being said, the arguments you repeat here have come up in
> previous threads and been responded to. This doesn't change my
> conclusion that your NAK is bogus.
>
They actually haven't been responded to, Roman was working through v11 and
made a change on how the root mem cgroup usage was calculated that was
better than previous iterations but still not an apples to apples
comparison with other cgroups. The problem is that it the calculation for
leaf cgroups includes additional memory classes, so it biases against
processes that are moved to non-root mem cgroups. Simply creating mem
cgroups and attaching processes should not independently cause them to
become more preferred: it should be a fair comparison between the root mem
cgroup and the set of leaf mem cgroups as implemented. That is very
trivial to do with hierarchical oom cgroup scoring.
Since the ability of userspace to control oom victim selection is not
addressed whatsoever by this patchset, and the suggested method cannot be
implemented on top of this patchset as you have argued because it requires
a change to the heuristic itself, the patchset needs to become complete
before being mergeable.
next prev parent reply other threads:[~2017-10-26 21:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 18:52 [RESEND v12 0/6] cgroup-aware OOM killer Roman Gushchin
2017-10-19 18:52 ` [RESEND v12 1/6] mm, oom: refactor the oom_kill_process() function Roman Gushchin
2017-10-19 18:52 ` [RESEND v12 2/6] mm: implement mem_cgroup_scan_tasks() for the root memory cgroup Roman Gushchin
2017-10-19 18:52 ` [RESEND v12 3/6] mm, oom: cgroup-aware OOM killer Roman Gushchin
2017-10-19 19:30 ` Michal Hocko
2017-10-31 15:04 ` Shakeel Butt
2017-10-31 15:29 ` Michal Hocko
2017-10-31 19:06 ` Michal Hocko
2017-10-31 19:13 ` Michal Hocko
2017-10-31 16:40 ` Johannes Weiner
2017-10-31 17:50 ` Shakeel Butt
2017-10-31 18:44 ` Johannes Weiner
2017-10-19 18:52 ` [RESEND v12 4/6] mm, oom: introduce memory.oom_group Roman Gushchin
2017-10-19 18:52 ` [RESEND v12 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer Roman Gushchin
2017-10-19 18:52 ` [RESEND v12 6/6] mm, oom, docs: describe the " Roman Gushchin
2017-10-19 19:45 ` [RESEND v12 0/6] " Johannes Weiner
2017-10-19 21:09 ` Michal Hocko
2017-10-23 0:24 ` David Rientjes
2017-10-23 11:49 ` Michal Hocko
2017-10-25 20:12 ` David Rientjes
2017-10-26 14:24 ` Johannes Weiner
2017-10-26 21:03 ` David Rientjes [this message]
2017-10-27 9:31 ` Roman Gushchin
2017-10-30 21:36 ` David Rientjes
2017-10-31 7:54 ` Michal Hocko
2017-10-31 22:21 ` David Rientjes
2017-11-01 7:37 ` Michal Hocko
2017-11-01 20:42 ` David Rientjes
2017-10-27 20:05 ` Johannes Weiner
2017-10-31 14:17 ` peter enderborg
2017-10-31 14:34 ` Michal Hocko
2017-10-31 15:07 ` peter enderborg
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.1710261359550.75887@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@suse.com \
--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).