Re: [PATCH 2/2] sched/fair: Avoid re-syncing runtime_enabled on root domain changes

[Qiliang Yuan <qiliang.yuan@linux.dev>]

On Thu, Nov 12, 2026 at 11:56:24AM +0100, Peter Zijlstra wrote:
> How do you end up with 4k cgroups ?!? That's wild.

It is common on hosts running AI agent harnesses: every agent sandbox
gets its own container, and each pod and container has a cgroup with
the cpu controller enabled, so a single kernel easily carries over a
thousand task groups. 4000 is the upper end of that, picked to show the
scaling.

> Also, why do you care about the rebuild performance? I'm not entirely
> sure it makes sense to add data for something that 'never' happens. Do
> we really need a new member variable for this?

On those setups it is not rare. Agent harnesses and KubeVirt both
hot-add and remove vCPUs at run time to follow the load, and every
hotplug rebuilds the sched domains of the guest.

A rebuild runs rq_attach_root() on every active CPU, and with the rq
lock held and interrupts disabled it walks all task groups twice. With
4000 cpu cgroups on a 32-CPU VM, one rq_attach_root() call takes 188 us
at the median and up to 938 us, against 2 us with both patches applied
(20 partition switches, 1280 calls). So every rebuild leaves each CPU
with interrupts off for close to a millisecond in the worst case.

The member is there because rq_online_fair() can't tell a rebuild from
a CPU coming up: the CPU is active in both cases, but only the latter
can have runtime_enabled out of date after unthrottle_offline_cfs_rqs().