From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, mm-commits@vger.kernel.org,
tj@kernel.org, guro@fb.com, dennis@kernel.org,
chris@chrisdown.name,
cgroups mailinglist <cgroups@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: + mm-consider-subtrees-in-memoryevents.patch added to -mm tree
Date: Thu, 16 May 2019 13:56:55 -0400 [thread overview]
Message-ID: <20190516175655.GA25818@cmpxchg.org> (raw)
In-Reply-To: <20190213124729.GI4525@dhcp22.suse.cz>
On Wed, Feb 13, 2019 at 01:47:29PM +0100, Michal Hocko wrote:
> On Tue 12-02-19 14:45:42, Andrew Morton wrote:
> [...]
> > From: Chris Down <chris@chrisdown.name>
> > Subject: mm, memcg: consider subtrees in memory.events
> >
> > memory.stat and other files already consider subtrees in their output, and
> > we should too in order to not present an inconsistent interface.
> >
> > The current situation is fairly confusing, because people interacting with
> > cgroups expect hierarchical behaviour in the vein of memory.stat,
> > cgroup.events, and other files. For example, this causes confusion when
> > debugging reclaim events under low, as currently these always read "0" at
> > non-leaf memcg nodes, which frequently causes people to misdiagnose breach
> > behaviour. The same confusion applies to other counters in this file when
> > debugging issues.
> >
> > Aggregation is done at write time instead of at read-time since these
> > counters aren't hot (unlike memory.stat which is per-page, so it does it
> > at read time), and it makes sense to bundle this with the file
> > notifications.
> >
> > After this patch, events are propagated up the hierarchy:
> >
> > [root@ktst ~]# cat /sys/fs/cgroup/system.slice/memory.events
> > low 0
> > high 0
> > max 0
> > oom 0
> > oom_kill 0
> > [root@ktst ~]# systemd-run -p MemoryMax=1 true
> > Running as unit: run-r251162a189fb4562b9dabfdc9b0422f5.service
> > [root@ktst ~]# cat /sys/fs/cgroup/system.slice/memory.events
> > low 0
> > high 0
> > max 7
> > oom 1
> > oom_kill 1
> >
> > As this is a change in behaviour, this can be reverted to the old
> > behaviour by mounting with the `memory_localevents' flag set. However, we
> > use the new behaviour by default as there's a lack of evidence that there
> > are any current users of memory.events that would find this change
> > undesirable.
> >
> > Link: http://lkml.kernel.org/r/20190208224419.GA24772@chrisdown.name
> > Signed-off-by: Chris Down <chris@chrisdown.name>
> > Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: Michal Hocko <mhocko@kernel.org>
> > Cc: Tejun Heo <tj@kernel.org>
> > Cc: Roman Gushchin <guro@fb.com>
> > Cc: Dennis Zhou <dennis@kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> FTR: As I've already said here [1] I can live with this change as long
> as there is a larger consensus among cgroup v2 users. So let's give this
> some more time before merging to see whether there is such a consensus.
>
> [1] http://lkml.kernel.org/r/20190201102515.GK11599@dhcp22.suse.cz
It's been three months without any objections. Can we merge this for
v5.2 please? We still have users complaining about this inconsistent
behavior (the last one was yesterday) and we'd rather not carry any
out of tree patches.
next prev parent reply other threads:[~2019-05-16 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190212224542.ZW63a%akpm@linux-foundation.org>
2019-02-13 12:47 ` Michal Hocko
2019-05-16 17:56 ` Johannes Weiner [this message]
2019-05-16 18:10 ` Michal Hocko
2019-05-16 19:39 ` Johannes Weiner
2019-05-17 12:33 ` Michal Hocko
2019-05-17 13:00 ` Shakeel Butt
2019-05-22 5:30 ` Suren Baghdasaryan
2019-05-18 1:33 ` Johannes Weiner
2019-05-22 2:23 ` Andrew Morton
2019-05-22 15:44 ` Johannes Weiner
2019-05-17 13:00 ` Shakeel Butt
2019-05-17 19:04 ` Johannes Weiner
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=20190516175655.GA25818@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=dennis@kernel.org \
--cc=guro@fb.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=tj@kernel.org \
/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