From: Tejun Heo <tj@kernel.org>
To: JP Kobryn <inwardvessel@gmail.com>
Cc: shakeel.butt@linux.dev, mhocko@kernel.org, hannes@cmpxchg.org,
yosryahmed@google.com, akpm@linux-foundation.org,
linux-mm@kvack.org, cgroups@vger.kernel.org
Subject: Re: [RFC PATCH 0/9 v2] cgroup: separate per-subsystem rstat trees
Date: Fri, 3 Jan 2025 12:08:39 -1000 [thread overview]
Message-ID: <Z3hf5wrRuw0KylTh@slm.duckdns.org> (raw)
In-Reply-To: <20250103015020.78547-1-inwardvessel@gmail.com>
Hello,
On Thu, Jan 02, 2025 at 05:50:11PM -0800, JP Kobryn wrote:
...
> I reached a point where this started to feel stable in my local testing, so I
> wanted to share and get feedback on this approach.
The rationale for using one tree to track all subsystems was that if one
subsys has been active (e.g. memory), it's likely that other subsyses have
been active too (e.g. cpu) and thus we might as well flush the whole thing
together. The approach can be useful for reducing the amount of work done
when e.g. there are a lot of cgroups which are only active periodically but
has drawbacks when one subsystem's stats are read a lot more actively than
others as you pointed out.
Intuitions go only so far and it's difficult to judge whether splitting the
trees would be a good idea without data. Can you please provide some
numbers along with rationales for the test setups?
Thanks.
--
tejun
next prev parent reply other threads:[~2025-01-03 22:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 1:50 JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 1/9 v2] cgroup: change cgroup to css in rstat updated and flush api JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 2/9 v2] cgroup: change cgroup to css in rstat internal flush and lock funcs JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 3/9 v2] cgroup: change cgroup to css in rstat init and exit api JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 4/9 v2] cgroup: split rstat from cgroup into separate css JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 5/9 v2] cgroup: separate locking between base css and others JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 6/9 v2] cgroup: isolate base stat flush JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 7/9 v2] cgroup: remove unneeded rcu list JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 8/9 v2] cgroup: remove bpf rstat flush from css generic flush JP Kobryn
2025-01-03 1:50 ` [RFC PATCH 9/9 v2] cgroup: avoid allocating rstat when flush func not present JP Kobryn
2025-01-03 22:08 ` Tejun Heo [this message]
2025-01-13 18:39 ` [RFC PATCH 0/9 v2] cgroup: separate per-subsystem rstat trees Shakeel Butt
2025-01-13 19:14 ` Tejun Heo
2025-01-06 23:13 ` Yosry Ahmed
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=Z3hf5wrRuw0KylTh@slm.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=inwardvessel@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=yosryahmed@google.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