[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZqQBaeAH_IfpRTnv@slm.duckdns.org>
Date: Fri, 26 Jul 2024 10:04:57 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Waiman Long <longman@...hat.com>, Zefan Li <lizefan.x@...edance.com>,
Johannes Weiner <hannes@...xchg.org>,
Jonathan Corbet <corbet@....net>, cgroups@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
Kamalesh Babulal <kamalesh.babulal@...cle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>
Subject: Re: [PATCH-cgroup v4] cgroup: Show # of subsystem CSSes in
cgroup.stat
Hello,
On Fri, Jul 26, 2024 at 10:19:05AM +0200, Michal Koutný wrote:
> On Thu, Jul 25, 2024 at 04:05:42PM GMT, Waiman Long <longman@...hat.com> wrote:
> > > There's also 'debug' subsys. Have you looked at (extending) that wrt
> > > dying csses troubleshooting?
> > > It'd be good to document here why you decided against it.
> > The config that I used for testing doesn't include CONFIG_CGROUP_DEBUG.
>
> I mean if you enable CONFIG_CGROUP_DEBUG, there is 'debug' controller
> that exposes files like debug.csses et al.
>
> > That is why "debug" doesn't show up in the sample outputs. The CSS #
> > for the debug subsystem should show up if it is enabled.
>
> So these "debugging" numbers could be implemented via debug subsys. So I
> wondered why it's not done this way. That reasoning is missing in the
> commit message.
While this is a bit of implementation detail, it's also something which can
be pretty relevant in production, so my preference is to show them in
cgroup.stat. The recursive stats is something not particularly easy to
collect from the debug controller proper anyway.
One problem with debug subsys is that it's unclear whether they are safe to
use and can be depended upon in production. Not that anything it shows
currently is particularly risky but the contract around the debug controller
is that it's debug stuff and developers may do silly things with it (e.g.
doing high complexity iterations and what not).
The debug controller, in general, I'm not sure how useful it is. It does
nothing that drgn scripts can't do and doesn't really have enough extra
benefits that make it better. We didn't have drgn back when it was added, so
it's there for historical reasons, but I don't think it's a good idea to
expand on it.
Thanks.
--
tejun
Powered by blists - more mailing lists