Received-SPF: pass (google.com: domain of linux-kernel+bounces-193191-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240528163713.2024887-1-tjmercier@google.com>
 <ZlYzzFYd0KgUnlso@slm.duckdns.org> <zrvsmkowongdaqcy3yqb6abh76utimen5ejrnkczd4uq3etesl@jv3xb4uso4yk>
In-Reply-To: <zrvsmkowongdaqcy3yqb6abh76utimen5ejrnkczd4uq3etesl@jv3xb4uso4yk>
From: "T.J. Mercier" <tjmercier@google.com>
Date: Tue, 28 May 2024 15:38:01 -0700
Message-ID: <CABdmKX2vmpFS=j_FoFOadHRVVWaWUsReJYv+dJNHosk1uE_Dvw@mail.gmail.com>
Subject: Re: [PATCH 1/2] cgroup: Fix /proc/cgroups count for v2
To: =?UTF-8?Q?Michal_Koutn=C3=BD?= <mkoutny@suse.com>
Cc: Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, shakeel.butt@linux.dev, cgroups@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 28, 2024 at 2:42=E2=80=AFPM Michal Koutn=C3=BD <mkoutny@suse.co=
m> wrote:
>
> On Tue, May 28, 2024 at 09:43:08AM GMT, Tejun Heo <tj@kernel.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 rathe=
r
> > 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.
>
Yeah, I meant this more as a fix for the current interface which would
still be wrong if we added a new file. I intended to find and add a
Fixes: line too, but I forgot!

> > 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.
>
This usually gets close but doesn't capture zombies, where /proc/cgroups do=
es.

memcg is enabled in every cgroup in this example, so just find all
dirs and count them without checking cgroup.subtree_control
# find /sys/fs/cgroup/ -type d|wc -l ; grep memory /proc/cgroups
440
memory 0 465 1

Last year I found a driver bug that was causing thousands of zombies
which I only noticed from the huge difference between these two
values.

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