Hi Umut. On Tue, Nov 25, 2025 at 08:28:18AM +0100, Umut Tezduyar Lindskog <[email protected]> wrote: > Specifically: doesn’t the default behavior pose a risk to the parent > hierarchy? Since the CPU controller is disabled at the slice level, a > malicious or misbehaving service that becomes aware of this could fork > large numbers of CPU-intensive processes. Because the parent slice does not > enforce CPU limits, this could cause other services within the same slice > to starve.
Yes, this is possible. The clarification to that is it wouldn't totally
starve other threads but "fairly" in relation to runnable population
sizes. [1]
> Shouldn't the CPU controller be "turned on by default" like the PID
> controller? Appreciate any clarification you can provide.
Group scheduling comes with an overhead -- that would be the reason to
keep it off by default. Then it boils to each distro [2] (or even
deployment) to decide how trusted/safe are the workloads in regards to
this trade-off. (The PID controller in comparison is cheaper so its
balance is different.)
HTH,
Michal
[1] Some back of the envelope calculation gives me that a "useful"
thread would be on CPU k/(n+1) of time where k is number of CPUs and
n is number of "wasteful" threads, assuming n > k.
[2] It also depends on whether kernel has CONFIG_SCHED_AUTOGROUP [3]
which partially substitutes potential systemd's fine groups.
[3] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=SCHED_AUTOGROUP
signature.asc
Description: PGP signature
