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

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

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

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.

quoted

(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?

-- 
Best regards,
Ridong