From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Chris Down <chris@chrisdown.name>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Roman Gushchin <guro@fb.com>,
Dennis Zhou <dennis@kernel.org>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, kernel-team@fb.com
Subject: Re: [PATCH 2/2] mm: Consider subtrees in memory.events
Date: Thu, 24 Jan 2019 11:00:10 -0500 [thread overview]
Message-ID: <20190124160009.GA12436@cmpxchg.org> (raw)
In-Reply-To: <20190124082252.GD4087@dhcp22.suse.cz>
On Thu, Jan 24, 2019 at 09:22:52AM +0100, Michal Hocko wrote:
> On Wed 23-01-19 17:31:44, Chris Down wrote:
> > Acked-by: Johannes Weiner <hannes@cmpxchg.org>
>
> btw. I do not see this patch posted anywhere yet it already comes with
> an ack. Have I just missed a previous version?
I reviewed it offline before Chris sent it out.
I agree with the sentiment that the non-hierarchical behavior was an
oversight, not a design decision.
The arguments against the change don't convince me: the added
difficulty of finding out local values is true for all other cgroup
files as well. This is traded off with being able to detect any
subtree state from the first level cgroups and drill down on-demand,
without having to scan the entire tree on each monitoring interval.
That's a trade-off we've made everywhere else, so this is simply an
inconsistency, not a legitimate exception to the rule.
We cannot fully eliminate a risk for regression, but it strikes me as
highly unlikely, given the extremely young age of cgroup2-based system
management and surrounding tooling.
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
next prev parent reply other threads:[~2019-01-24 16:00 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 22:31 [PATCH 2/2] mm: Consider subtrees in memory.events Chris Down
2019-01-24 0:24 ` Roman Gushchin
2019-01-24 1:03 ` Chris Down
2019-01-24 8:22 ` Michal Hocko
2019-01-24 15:21 ` Tejun Heo
2019-01-24 15:51 ` Michal Hocko
2019-01-24 16:00 ` Johannes Weiner [this message]
2019-01-24 17:01 ` Michal Hocko
2019-01-24 18:23 ` Johannes Weiner
2019-01-25 8:42 ` Michal Hocko
2019-01-25 16:51 ` Tejun Heo
2019-01-25 17:37 ` Michal Hocko
2019-01-25 17:37 ` Michal Hocko
2019-01-25 18:28 ` Tejun Heo
2019-01-28 12:51 ` Michal Hocko
2019-01-28 14:28 ` Tejun Heo
2019-01-28 14:52 ` Michal Hocko
2019-01-28 14:54 ` Tejun Heo
2019-01-28 15:18 ` Michal Hocko
2019-01-28 15:41 ` Tejun Heo
2019-01-28 17:05 ` Michal Hocko
2019-01-28 17:05 ` Michal Hocko
2019-01-28 17:49 ` Tejun Heo
2019-01-28 17:49 ` Tejun Heo
2019-01-29 14:43 ` Michal Hocko
2019-01-29 14:52 ` Tejun Heo
2019-01-30 16:50 ` Michal Hocko
2019-01-30 17:06 ` Tejun Heo
2019-01-30 17:41 ` Michal Hocko
2019-01-30 17:52 ` Tejun Heo
2019-01-30 18:16 ` Michal Hocko
2019-01-30 19:11 ` Shakeel Butt
2019-01-30 19:27 ` Johannes Weiner
2019-01-30 19:30 ` Johannes Weiner
2019-01-30 19:37 ` Shakeel Butt
2019-01-30 19:23 ` Johannes Weiner
2019-01-30 20:05 ` Michal Hocko
2019-01-30 21:31 ` Johannes Weiner
2019-01-31 8:58 ` Michal Hocko
2019-01-31 16:22 ` Johannes Weiner
2019-02-01 10:27 ` Michal Hocko
2019-02-01 16:34 ` Johannes Weiner
2019-01-28 15:59 ` Shakeel Butt
2019-01-28 15:59 ` Shakeel Butt
2019-01-28 16:05 ` Tejun Heo
2019-01-28 16:05 ` Tejun Heo
2019-01-28 16:08 ` Shakeel Butt
2019-01-28 16:08 ` Shakeel Butt
2019-01-28 16:12 ` Tejun Heo
2019-01-28 16:12 ` Tejun Heo
2019-01-28 14:30 ` Tejun Heo
2019-02-08 22:43 ` [PATCH v2 1/2] mm: Rename ambiguously named memory.stat counters and functions Chris Down
2019-02-08 22:44 ` [PATCH v2 2/2] mm: Consider subtrees in memory.events Chris Down
2019-02-11 19:01 ` Johannes Weiner
2019-02-11 18:55 ` [PATCH v2 1/2] mm: Rename ambiguously named memory.stat counters and functions 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=20190124160009.GA12436@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=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@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;
as well as URLs for NNTP newsgroup(s).