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 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]>
