Re: [PATCH v3 1/2] cgroup: Show # of subsystem CSSes in cgroup.stat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7/11/24 13:18, Tejun Heo wrote:
Hello,

On Thu, Jul 11, 2024 at 10:05:22AM -0400, Waiman Long wrote:
Given the fact that for_each_css() iteration is filtering out csses that are
absent, the dying counts follow the same logic of skipping it if there is no
dying css. That also makes it easier to identify cgroups with dying
descendant csses as we don't need filter out entries with a 0 dying count.
It also makes the output less verbose and let user focus more on what are
significant.

I do understand that it makes it inconsistent with the ways nr_descendants
and nr_dying_descendants are being handled as entries with 0 count are also
displayed. I can update the patch to display those entries with 0 dying
subsys count if other people also think that is the better way forward.
I think it'd be better to have all the keys. There are some dynamic keys in
stat files but those are mostly for things which can come and go (e.g. block
and misc devices), so yeah, I think it'd be better to show all the keys even
when they're zero.
Currently, I use the for_each_css() macro for iteration. If you mean displaying all the possible cgroup subsystems even if they are not enabled for the current cgroup, I will have to manually do the iteration.

Also, I personally would much prefer if the same prefixes are collected
together - ie. totals first and then dying. It's just a lot easier on the
eyes that way.

	nr_subsys_cpu
	nr_subsys_memory
	nr_subsys_io
	...
	nr_dying_subsys_cpu
	nr_dying_subsys_memory
	nr_dying_subsys_io
	...

That is fine. I can group entries with the same prefix together.

Cheers,
Longman





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux