From: peter enderborg <peter.enderborg@sonymobile.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
David Rientjes <rientjes@google.com>,
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: Tue, 31 Oct 2017 16:07:42 +0100 [thread overview]
Message-ID: <311d5313-5a51-fded-714b-420ba3f6a879@sonymobile.com> (raw)
In-Reply-To: <20171031143422.dnm3wvkl4v6qngtv@dhcp22.suse.cz>
On 10/31/2017 03:34 PM, Michal Hocko wrote:
> On Tue 31-10-17 15:17:11, peter enderborg wrote:
>> On 10/27/2017 10:05 PM, Johannes Weiner wrote:
>>> On Thu, Oct 26, 2017 at 02:03:41PM -0700, David Rientjes wrote:
>>>> 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.
>>> There is absolutely no value in your repeating the same stuff over and
>>> over again without considering what other people are telling you.
>>>
>>> Hierarchical oom scoring has other downsides, and most of us agree
>>> that they aren't preferable over the differences in scoring the root
>>> vs scoring other cgroups - in particular because the root cannot be
>>> controlled, doesn't even have local statistics, and so is unlikely to
>>> contain important work on a containerized system. Getting the ballpark
>>> right for the vast majority of usecases is more than good enough here.
>>>
>>>> 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.
>>> It is complete. It just isn't a drop-in replacement for what you've
>>> been doing out-of-tree for years. Stop making your problem everybody
>>> else's problem.
>>>
>>> You can change the the heuristics later, as you have done before. Or
>>> you can add another configuration flag and we can phase out the old
>>> mode, like we do all the time.
>>>
>> I think this problem is related to the removal of the lowmemorykiller,
>> where this is the life-line when the user-space for some reason fails.
>>
>> So I guess quite a few will have this problem.
> Could you be more specific please? We are _not_ removing possibility of
> the user space influenced oom victim selection. You can still use the
> _current_ oom selection heuristic. The patch adds a new selection method
> which is opt-in so only those who want to opt-in will not be allowed to
> have any influence on the victim selection. And as it has been pointed
> out this can be implemented later so it is not like "this won't be
> possible anymore in future"
I think the idea is to have a implementation that is lowmemorykiller selection heuristic.
prev parent reply other threads:[~2017-10-31 15:07 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
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 [this message]
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=311d5313-5a51-fded-714b-420ba3f6a879@sonymobile.com \
--to=peter.enderborg@sonymobile.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=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).