Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32

[Waiman Long <llong@redhat.com>]

On 1/29/26 4:51 AM, Chen Ridong wrote:
>
> On 2026/1/29 17:23, Michal Koutný wrote:
>> On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong <chenridong@huaweicloud.com> wrote:
>>> From: Chen Ridong <chenridong@huawei.com>
>>>
>>> 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'.
>
>>> 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.
>
>>> 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>