From: "Barro Raffel, Willy" <willybar@amazon.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Bouron, Justinien" <jbouron@amazon.com>,
"Kudrjavets, Gunnar" <gunnarku@amazon.com>
Subject: Re: [PATCH] cgroup: add cpu.stat.percpu for per-CPU cgroup stats
Date: Wed, 8 Apr 2026 18:31:02 +0000 [thread overview]
Message-ID: <adae5DmaDwYN3f50@6c7e67b75e78> (raw)
In-Reply-To: <tqtihhcvq26p22eeisy5z3odtnflukoi6lh272gwr66tdj34te@s57ny333owxe>
On Wed, Apr 08, 2026 at 02:30:11PM +0200, Michal Koutný wrote:
> ...
>The argument "to complete the interface" explains the actual need for
>such a new attribute not convincingly.
>
>Willy, what is the expected use of these per-cgroup per-cpu stats?
>(Given there's: global per-cpu stat, per-cgroup total stat, cpusets for
>binding and the mentioned bpf/drgn availability for precise
>control/debugging.)
Our use case is that we run systems where services in separate cgroups
are pinned to specific CPUs via sched_setaffinity (not cgroup cpusets).
We need to know how much of each core's time each cgroup is consuming,
particularly on shared cores where multiple services compete. I believe
this use case is not unique to us.
/proc/stat gives per-CPU totals without per-cgroup breakdown.
cpu.stat gives per-cgroup totals without per-CPU breakdown.
Neither answers "how much of core N is cgroup X using?"
The data already exists in subtree_bstat per CPU. BPF can access
per-cgroup totals, but reading the per-CPU subtree_bstat requires either
Clang-compiled kernels (for percpu type tags) or custom kfuncs IIRC,
which are nontrivial dependencies for simple monitoring.
>Thanks,
>Michal
Regarding output format: I'm open to a more compact format if preferred,
for example, skip CPUs with zero stats, skip offline CPUs, using a
simpler positional format without keys, or a mix of all these ideas.
I personally prefer clear key-value pairs that don't require the
developer/operator/human to need to go to the manual just to find out
what a number in a certain position means.
Happy to adjust based on what you all think fits best though.
Thanks! Willy
prev parent reply other threads:[~2026-04-08 18:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 1:06 [PATCH] cgroup: add cpu.stat.percpu for per-CPU cgroup stats Willy Barro Raffel
2026-04-07 18:27 ` Tejun Heo
2026-04-07 20:24 ` Barro Raffel, Willy
2026-04-08 12:30 ` Michal Koutný
2026-04-08 18:31 ` Barro Raffel, Willy [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=adae5DmaDwYN3f50@6c7e67b75e78 \
--to=willybar@amazon.com \
--cc=cgroups@vger.kernel.org \
--cc=gunnarku@amazon.com \
--cc=hannes@cmpxchg.org \
--cc=jbouron@amazon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.