On 2026/1/30 2:33, Waiman Long wrote:
> 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
>>> <[email protected]> wrote:
>>>> From: Chen Ridong <[email protected]>
>>>>
>>>> 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
Thanks, Longman,
Now that dmem has been added, I believe a new subsystem for GPU scheduling will
be introduced soon.
> 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 <[email protected]>
>
>
--
Best regards,
Ridong
