Re: [PATCH/for-next v4 2/4] cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue

[Frederic Weisbecker <frederic@kernel.org>]

Le Sat, Feb 07, 2026 at 09:00:45PM -0500, Waiman Long a écrit :
> On 2/6/26 5:28 PM, Frederic Weisbecker wrote:
> > Le Fri, Feb 06, 2026 at 03:37:10PM -0500, Waiman Long a écrit :
> > > The update_isolation_cpumasks() function can be called either directly
> > > 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
> > Why do we need to call housekeeping_update() from hotplug? I would
> > 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.
> 
> It needs to call housekeeping_update() only in the special case where there
> 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.

But why is that needed? This isn't changing the mask of domain isolated CPUs.
Only their onlineness. I mean timers, workqueue, kthreads all have their
hotplug callbacks able to deal with that already.

> Theoretically, we can add code to handle this special case to keep this
> 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.

That doesn't look necessary.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs