linux-kernel - cpu.stat in core or cpu controller (was Re: [RFC PATCH v2] cgroup: Track time in cgroup v2 freezer)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <jyvlpm6whamo5ge533xdsvqnsjsxdonpvdjbtt5gqvcw5fjp56@q4ej7gy5frj7>
Date: Fri, 18 Jul 2025 15:58:58 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Chen Ridong <chenridong@...weicloud.com>
Cc: Tejun Heo <tj@...nel.org>, Tiffany Yang <ynaffit@...gle.com>, 
	linux-kernel@...r.kernel.org, John Stultz <jstultz@...gle.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, 
	Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Pavel Machek <pavel@...nel.org>, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Chen Ridong <chenridong@...wei.com>, kernel-team@...roid.com, Jonathan Corbet <corbet@....net>, 
	cgroups@...r.kernel.org, linux-doc@...r.kernel.org
Subject: cpu.stat in core or cpu controller (was Re: [RFC PATCH v2] cgroup:
 Track time in cgroup v2 freezer)

On Fri, Jul 18, 2025 at 05:26:54PM +0800, Chen Ridong <chenridong@...weicloud.com> wrote:
> With the recent merge of the series "cgroup: separate rstat trees," the rstat are not bound to CPU
> system. This makes me wonder: should we consider moving the cpu.stat and cpu.stat.local interfaces
> to the CPU subsystem?

Note that fields printed in cpu.stat are combination of "core" and cpu
controller values.

> The CPU subsystem could then align more closely with other resource controllers like memory or I/O
> subsystems. By decoupling these CPU-specific statistics from the cgroup core, it could help keep
> both cgroup and rstat implementations more focused.

In my eyes, cpu controller is stuff encapsulated by cpu_cgrp_subsys. I'm
not sure I understand what you refer to as the CPU subsystem.

One thing is how it is presented to users (filenames and content)
another one is how it is implemented. The latter surely can be
refactored but it's not obvious to me from the short description, sorry.

> Is there any particular reason why the CPU subsystem must remain bound
> to the cgroup core?

The stuff that's bound to the core is essentially not "control" but only
accounting, so with this association, the accounting can have fine
granularity while control (which incurs higher overhead in principle)
may remain coarse. I find it thus quite fitting that CPU stats build on
top of rstat.
(Naturally, my previous claim about overhead is only rough and it's the
reason for existence of adjustments like in the commit 34f26a15611af
("sched/psi: Per-cgroup PSI accounting disable/re-enable interface").)

Thats how I see it, happy to discuss possible problems you see with
this.

Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)