From: Tejun Heo <tj@kernel.org>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: JP Kobryn <inwardvessel@gmail.com>,
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: Mon, 13 Jan 2025 09:14:40 -1000 [thread overview]
Message-ID: <Z4VmIHRlwYczKFfe@slm.duckdns.org> (raw)
In-Reply-To: <zwdpnhzxebx64pbvd5wtwje6gixbu4lifw2qzrmnybledtform@cc6g4bznoz6v>
Hello,
On Mon, Jan 13, 2025 at 10:39:02AM -0800, Shakeel Butt wrote:
...
> Here I think the supportive data we can show is the (1) non-memory stats
> readers not needing to spend time on memory stats flushing and (2) with
> per-subsystem update tree, have we increased the cost of update tree
> insertion in general?
>
> Anything else you think will be needed?
Anything that shows:
1. It doesn't cause noticeable regressions for generic use cases.
2. It has noticeable benefits in the targeted use cases.
The above is a bit willy-nilly but 2 should be fairly straightforward. For
1, the main worry would be whether high(er) frequency monitoring using
something like systemd-cgtop or below becomes noticeably more expensive on a
large and busy system.
Thanks.
--
tejun
next prev parent reply other threads:[~2025-01-13 19:14 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 ` [RFC PATCH 0/9 v2] cgroup: separate per-subsystem rstat trees Tejun Heo
2025-01-13 18:39 ` Shakeel Butt
2025-01-13 19:14 ` Tejun Heo [this message]
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=Z4VmIHRlwYczKFfe@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