Re: [PATCH] cgroup/cpuset: Call rebuild_sched_domains() directly in hotplug

[Waiman Long <longman@redhat.com>]

On 3/5/26 8:54 AM, Frederic Weisbecker wrote:
> Le Wed, Mar 04, 2026 at 01:41:00PM -0500, Waiman Long a écrit :
>> Besides deferring the call to housekeeping_update(), commit 6df415aa46ec
>> ("cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug
>> to workqueue") also defers the rebuild_sched_domains() call to
>> the workqueue. So a new offline CPU may still be in a sched domain
>> or new online CPU not showing up in the sched domains for a short
>> transition period. That could be a problem in some corner cases and
>> can be the cause of a reported test failure[1]. Fix it by calling
>> rebuild_sched_domains_cpuslocked() directly in hotplug as before. If
>> isolated partition invalidation or recreation is being done, the
>> housekeeping_update() call to update the housekeeping cpumasks will
>> still be deferred to a workqueue.
>>
>> In commit 3bfe47967191 ("cgroup/cpuset: Move
>> housekeeping_update()/rebuild_sched_domains() together"),
>> housekeeping_update() is called before rebuild_sched_domains() because
>> it needs to access the HK_TYPE_DOMAIN housekeeping cpumask. That is now
>> changed to use the static HK_TYPE_DOMAIN_BOOT cpumask as HK_TYPE_DOMAIN
>> cpumask is now changeable at run time.  As a result, we can move the
> But rebuild_sched_domains() will still handle the cpuset isolated partitions
> somehow right? Sorry for the question, I'm a bit lost in the
> partition_sched_domains() maze...

For v2, generate_sched_domains() has no dependency on housekeeping 
cpumasks other that the HK_TYPE_DOMAIN_BOOT to strip out boot-time 
isolated CPUs from the effective_cpus of top_cpuset. So 
rebuild_sched_domains() will do the right thing even if HK cpumasks 
haven't been fully updated yet. Please let me know if you can think of 
any corner cases that will still be problematic.

Cheers, Longman