On Tue, May 28, 2024 at 2:42 PM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > On Tue, May 28, 2024 at 09:43:08AM GMT, Tejun Heo <tj@xxxxxxxxxx> 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. > 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 does. 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
