Message-ID: <e065b8da-9e7c-4214-9122-83d83700a729@huaweicloud.com>
Date: Sat, 19 Jul 2025 10:01:07 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.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: Re: cpu.stat in core or cpu controller (was Re: [RFC PATCH v2]
 cgroup: Track time in cgroup v2 freezer)



On 2025/7/18 21:58, Michal Koutný wrote:
> 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.
> 

Do you mean the "core" values are shown as below:
- usage_usec
- user_usec
- system_usec
- nice_usec

In the legacy cgroup, these values are in the cpuacct subsystem.

>> 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.
> 

What I'm considering is moving the implementation of cpu.stat from cgroup_base_files to
cpu_cgrp_subsys—without changing the user-facing interface (filenames and content remain the same).
However, the interface would only appear if the CPU subsystem is enabled.

Currently, cpu.stat and cpu.stat.local are visible in every cgroup, even when the CPU subsystem is
disabled. The only populated fields in such cases are:

- usage_usec
- user_usec
- system_usec
- nice_usec

I’m unsure whether this change would be acceptable?

>> 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.

The implementation would still rely on rstat, similar to memory.stat and io.stat. The goal is to
decouple it from the cgroup core (cgroup.c and rstat.c) while preserving accounting granularity.

Best regards,
Ridong

> (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

Powered by blists - more mailing lists