Re: [RFC PATCH 0/2] Add queue_*() functions and prefer per-cpu workqueue and flag

[Tejun Heo <tj@kernel.org>]

On Wed, Jul 08, 2026 at 03:58:58PM +0200, Frederic Weisbecker wrote:
> Le Wed, Jun 24, 2026 at 09:46:55AM -1000, Tejun Heo a écrit :
> > Hello,
> > 
> > On Tue, Jun 23, 2026 at 05:13:31PM +0200, Marco Crivellari wrote:
> > > > - At boot time, allow selecting whether to back them with percpu wqs or
> > > >   WQ_AFFN_X unbound ones. Maybe we can even experiment with default to
> > > >   WQ_AFFN_CPU.
> > > 
> > > You mentioned here "at boot time". What about making this also dynamic,
> > > "moving" the WQs with WQ_PREFER_PERCPU away from CPU N when N is
> > > isolated through a cgroup isolated partition?
> > 
> > Yeah, being dynamic is better but switching dynamically between percpu and
> > unbound workqueues feels like it's going to be complicated. I can't think of
> > a simple way to do that. If you can, please be my guest.
> 
> I fear it's necessary to have dynamic isolation working correctly.
> One way could be to make wq::cpu_pwq point to a pair of pwqs. One
> for the isolated -> unbound configuration and another one for the
> non_isolated -> per_cpu configuration.

So, if we really want this, I think a better way to go about it is probably
going deeper with the restructuring and just merge percpu and unbound
workqueues. Unbound workqueues already have the ability to update pwqs (or
rather install new ones and drain old ones), which is how attribute changes
are implemented. If we make the pwqs be able to point to both unbound and
percpu pools, the dynamic switch falls out naturally and percpu just becomes
one of the affinity settings. Luckily, recent developmenets on unbound
workqueue side already brought it pretty close to percpu already, so
hopefully it may not be *that* complicated.

Thanks.

-- 
tejun