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

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

On Fri, Nov 13, 2026 at 11:57:54AM +0530, K Prateek Nayak wrote:
> Question: Why do we need to do rq_offline_fair() + rq_online_fair()
> during cpuset for active CPUs since fair doesn't have any accounting
> linked to rd at all?
>
> For deadline and RT it makes sense for bandwidth accounting and
> rto_mask updates on new rd but fair, and ext shouldn't really
> care for a rd change.
>
> Would it make sense to separate the offline / online bits from
> a root domain switch? It won't speed up hotplug but it should
> speed up cpusets causing domain rebuilds.
[...]

Agreed, fair has nothing to redo when an active CPU only moves to a
new root domain.

Peter, I have a v2 that follows your earlier suggestion: rq_online()
and rq_offline() get a bool that says whether the CPU changes state,
and fair skips both walks when it doesn't. Hotplug gets faster as well,
since every hotplug rebuilds the domains and moves the other active
CPUs. With 4000 cpu cgroups on a 32-CPU VM, switching a 4-CPU cpuset
to a partition root and offlining or onlining one CPU take (median of
20 partition switches and 16 hotplug operations):

  operation         before (ms)  after (ms)  change
  partition root          19.73        1.19    -94%
  cpu offline             44.93       12.83    -71%
  cpu online              37.03       12.94    -65%

Prateek's split should give the same results and keeps the root domain
switch out of rq_online()/rq_offline(), which reads cleaner. One
difference: with it, a CPU coming up gets rq_online() from
sched_set_rq_online() after the rebuild, while today and in my v2 it
gets it from rq_attach_root() during the rebuild.

Which way would you prefer? I can post the v2 as it is, or rework it on
top of Prateek's patch.

Thanks,
Qiliang