On 1/29/26 4:51 AM, Chen Ridong wrote:

On 2026/1/29 17:23, Michal Koutný wrote:

quoted

On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong [off-list ref] wrote:

quoted

From: Chen Ridong <redacted>

The current cgroup subsystem limit of 16 is insufficient, as the number of
subsystems has already reached this maximum.

Indeed. But some of them are legacy (and some novel). Do you really need
one kernel image with every subsys config enabled?

We compiled with 'make allmodconfig'.

quoted

quoted

Attempting to add new subsystems beyond this limit results in boot
failures.

That sounds like BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) doesn't trigger
during build for you. Is the macro broken?

The BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) macro worked correctly. However, I
only modified the code to allow compilation to pass, and the system subsequently
failed to boot.

quoted

quoted

This patch increases the maximum number of supported cgroup subsystems from
16 to 32, providing adequate headroom for future subsystem additions.

It may be needed one day but I'd suggest binding this change with
introduction of actual new controller.
(As we have some CONFIG_*_V1 options that default to N, I'm thinking
about switching config's default to N as well (like:
CONFIG_CGROUP_CPUACCT CONFIG_CGROUP_DEVICE CONFIG_CGROUP_FREEZER
CONFIG_CGROUP_DEBGU), arch/x86/configs/x86_64_defconfig is not exactly
pinnacle of freshness :-/)

Can I propose increasing the maximum number now? If we switch certain configs to
default N and then a new subsystem is added later, the default configuration may
work fine, but it will become a problem under allmodconfig — which some users
actually rely on.

Besides, this shouldn't be a major change, right?

Yes, I agreed that it is not a major change. I count the number of 
SUBSYS() in include/linux/cgroup_subsys.h and there are exactly 16 of 
them. So introduction of a new cgroup subsystem will break the current 
limit. I remember that there was talk about adding scheduling cgroup on 
the GPU side. One day, a new cgroup subsystem may be added without the 
awareness that the subsystem limit has to be extended causing issue down 
the line. So I support the idea of extending it now so that there is one 
less thing to worry about when a new cgroup subsystem is added in the 
future.

Acked-by: Waiman Long <longman@redhat.com>