Re: [RFC PATCH v5 20/29] sched/deadline: Allow deeper hierarchies of RT cgroups

Tejun Heo
2026-05-05T19:56:59Z

Hello,

Some high level comments:

- Please align it with existing cgroup2 interface files. See cpu.max. This
can be e.g. cpu.rt.max without about the same semantics.

- cgroup2 enforces that internal cgroups w/ controllers enabled cannot have
threads in them. No need to enforce that separately.

- However, the cpu controller is a threaded controller which means that it
can have threaded sub-hierarchy where the no-internal-process rule doesn't
apply. This was created explicitly for cpu controller. The proposed change
blocks it effectively forcing cpu controller into regular domain
controller behavior subject to no-internal-process rule. Note these are
enforced at controller granularity and this means that users who use the
threaded mode will be forced to pick between the two.

- This has the same problem with cgroup1's rt cgroup sched support where
there is no way to have a permissive default configuration, which means
that users who don't really care about distributing rt shares
hierarchically would get blocked from running rt processes by default,
which basically forces distros to disable rt cgroup sched support. This is
not new but it'd be a shame to put in all the work and the end result is
that most people don't even have access to the feature.

Here's my suggestion if there is desire for this to become something most
people have easy access to:

- Don't make it impossible to use in conjunction with other resource control
mechanisms especially not CPU controller itself. Don't force people to
choose between threaded mode and rt control. Allow them to co-exist in a
reasonable manner.

- The same in the wider scope. Don't let it get in the way of people who
don't care about it. Compromising on interface / failure mode is better
than people not being able to use it in most cases.

Thanks.

--
tejun