Re: [PATCH/for-next v4 2/4] cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue
From: Waiman Long
Date: Tue Feb 10 2026 - 13:55:10 EST
On 2/10/26 10:46 AM, Frederic Weisbecker wrote:
Le Sat, Feb 07, 2026 at 09:00:45PM -0500, Waiman Long a écrit :
On 2/6/26 5:28 PM, Frederic Weisbecker wrote:But why is that needed? This isn't changing the mask of domain isolated CPUs.
Le Fri, Feb 06, 2026 at 03:37:10PM -0500, Waiman Long a écrit :It needs to call housekeeping_update() only in the special case where there
The update_isolation_cpumasks() function can be called either directlyWhy do we need to call housekeeping_update() from hotplug? I would
from regular cpuset control file write with cpuset_full_lock() called
or via the CPU hotplug path with cpus_write_lock and cpuset_mutex held.
As we are going to enable dynamic update to the nozh_full housekeeping
cpumask (HK_TYPE_KERNEL_NOISE) soon with the help of CPU hotplug,
allowing the CPU hotplug path to call into housekeeping_update() directly
from update_isolation_cpumasks() will likely cause deadlock. So we
expect it to be called only when cpuset control file are written since
housekeeping cpumask don't deal with online CPUs but with possible
CPUs.
is only one active CPU in an isolated partition and that CPU goes offline.
In this case, the partition becomes disabled that causes change in the
isolated CPUs. I know this special case shouldn't happen in real world, but
I do have test case to test that.
Only their onlineness. I mean timers, workqueue, kthreads all have their
hotplug callbacks able to deal with that already.
The current behavior is to remove the CPUs from the cpuset.cpus.isolated when an isolated partition is invalidated. It doesn't currently differentiate if that is from hotplug or by writing to the cpuset control files. I am planning to handle handle hotplug differently so that it won't need to change cpuset.cpus.isolated.
Theoretically, we can add code to handle this special case to keep thisThat doesn't look necessary.
offline isolated CPU in a special pool without changing isolated_cpus and
hence HK_TYPE_DOMAIN cpumask. In this way, we shouldn't need to call
housekeeping_update() from CPU hotplug. I will probably do that as CPU
hotplug will be used when we make HK_TYPE_KERNEL_NOISE cpumask dynamic in
the near future.
Yes, I think we can use the existing infrastructure to handle it without the need to add a special pool.
Cheers,
Longman