[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <zrvsmkowongdaqcy3yqb6abh76utimen5ejrnkczd4uq3etesl@jv3xb4uso4yk>
Date: Tue, 28 May 2024 23:42:13 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Tejun Heo <tj@...nel.org>
Cc: "T.J. Mercier" <tjmercier@...gle.com>,
Zefan Li <lizefan.x@...edance.com>, Johannes Weiner <hannes@...xchg.org>, shakeel.butt@...ux.dev,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] cgroup: Fix /proc/cgroups count for v2
On Tue, May 28, 2024 at 09:43:08AM GMT, Tejun Heo <tj@...nel.org> wrote:
> I agree that this can be a useful metric but am not sure /proc/cgroups is
> the right place to put it. Its use of v1 controller names, listing of
> controllers that don't exist in v2 and the unnecessary column are rather
> ugly and unnecessary.
At the same time, the info provided currently is incorrect or at least
misleading (when only v2 hierarchy is mounted, it mixes the counts) --
that's what T.J.'s patch attempts to rectify in my understanding.
> In v2, cgroup.controllers and cgroup.subtree_control govern which
> controllers are available and enabled in the subtree.
Yes, users could sum up cgroup.controllers contents for true v2
fingerprint.
> I think it would make sense to introduce something in a similar
> fashion. Can't think of a good name off the top of my head but add a
> cgroup. file which lists the controllers in the subtree along with the
> number of css's.
BTW, there is the 'debug' subsys that has (almost) exactly that:
'debug.csses' -- it's in v1 fashion though so it won't show hierarchical
sums.
Michal
Powered by blists - more mailing lists