On 7/11/24 17:00, Waiman Long wrote:
On 7/11/24 15:59, Johannes Weiner wrote:
On Thu, Jul 11, 2024 at 03:13:12PM -0400, Waiman Long wrote:
On 7/11/24 14:59, Tejun Heo wrote:
On Thu, Jul 11, 2024 at 02:51:38PM -0400, Waiman Long wrote:
On 7/11/24 14:44, Tejun Heo wrote:
Hello,
On Thu, Jul 11, 2024 at 01:39:38PM -0400, Waiman Long wrote:
On 7/11/24 13:18, Tejun Heo wrote:
...
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.
Just wrapping it with for_each_subsys() should do, no?
for_each_css() won't
iterate anything if css doesn't exist for the cgroup.
OK, I wasn't sure if you were asking to list all the possible
cgroup v2
cgroup subsystems even if they weren't enabled in the current cgroup.
Apparently, that is the case. I prefer it that way too.
Yeah, I think listing all is better. If the list corresponded
directly to
cgroup.controllers, it may make sense to only show enabled ones but
we can
have dying ones and implicitly enabled memory and so on, so I think
it'd be
cleaner to just list them all.
That will means cgroup subsystems that are seldomly used like rdma,
misc
or even hugetlb will always be shown in all the cgroup.stat output. I
actually prefer just showing those that are enabled. As for dying
memory
cgroups, they will only be shown in its online ancestors. We currently
don't know how many level down are each of the dying ones.
It seems odd to me to not show dead ones after a cgroup has disabled
the controller again. They still consume memory, after all, and so
continue to be property of that cgroup afterwards.
Instead of doing for_each_css(), would it make more sense to have
struct cgroup {
...
int nr_dying_subsys[CGROUP_SUBSYS_COUNT];
What exactly does new this array for? Is this for copying out
css->nr_dying_descendants before disabling a controller? The number
may be out of date when it is used. I would think we should store the
actual css and clearing it again once the css is ready to be freed.
Anyway, I would suggest doing it as a separate add-on patch if we
decide to do it instead of adding it to the current patch.
Alternatively, we could delay the clearing of cgroup->subsys[] entry
from offline time to until the css is ready to be freed. We do need to
add check about the CSS_ONLINE flag when we only want to deal with
online csses.
Cheers,
Longman