From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, 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: Mon, 23 Oct 2017 13:49:48 +0200 [thread overview]
Message-ID: <20171023114948.qzmo7emqbigfff7h@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1710221715010.70210@chino.kir.corp.google.com>
On Sun 22-10-17 17:24:51, David Rientjes wrote:
> On Thu, 19 Oct 2017, Johannes Weiner wrote:
>
> > David would have really liked for this patchset to include knobs to
> > influence how the algorithm picks cgroup victims. The rest of us
> > agreed that this is beyond the scope of these patches, that the
> > patches don't need it to be useful, and that there is nothing
> > preventing anyone from adding configurability later on. David
> > subsequently nacked the series as he considers it incomplete. Neither
> > Michal nor I see technical merit in David's nack.
> >
>
> 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,
Most users who are going to use this feature right now will have
most of the userspace in their containers rather than in the root
memcg. The root memcg will always be special and as such there will
never be a universal best way to handle it. We should to satisfy most of
usecases. I would consider this something that is an open for a further
discussion but nothing that should stand in the way.
> (2) the ability of users to completely evade the oom killer by attaching
> all processes to child cgroups either purposefully or unpurposefully,
> and
This doesn't differ from the current state where a task can purposefully
or unpurposefully hide itself from the global memory killer by spawning
new processes.
> (3) the inability of userspace to effectively control oom victim
> selection.
this is not requested by the current usecase and it has been pointed out
that this will be possible to implement on top of the foundation of this
patchset.
So again, nothing to nack the work as is.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2017-10-23 11:49 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 [this message]
2017-10-25 20:12 ` David Rientjes
2017-10-26 14:24 ` Johannes Weiner
2017-10-26 21:03 ` David Rientjes
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=20171023114948.qzmo7emqbigfff7h@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--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=penguin-kernel@i-love.sakura.ne.jp \
--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: 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).