Re: [PATCH 5/6] workqueue: add a per-cpu backend for unbound pwqs

[Breno Leitao]

On Sun, Aug 02, 2026 at 02:36:52PM -1000, Tejun Heo wrote:
> Hello,
> 
> On Fri, Jul 31, 2026 at 04:57:37AM -0700, Breno Leitao wrote:
> > Add alloc_percpu_pwq(), which binds a pwq to get_percpu_pool(wq, cpu),
> > and an internal __WQ_PERCPU_POOLS flag. unbound_wq_update_pwq() installs
> > such a pwq per CPU when the flag is set, reusing the existing
> > install/drain path. Pool release and nr_active are already keyed on the
> > backing pool, so a per-cpu-backed pwq is torn down and throttled
> > correctly.
> > 
> > PS: We can do this using if/else for per cpu/unbound as well, instead of
> > this labels:, would it be better?
> 
> So, we would have percpu-pool backed unbound workqueues in addition to the
> existing percpu workqueues? I'm not sure that makes sense. What prevents
> unifying them?

Nothing fundamental. What I'm working out here is how to plug the unbound
pwq machinery into the percpu pools, and I came up with this
__WQ_PERCPU_POOLS.

I am trying to following what you said here:
described in https://lore.kernel.org/all/ak569WYSm3ygKl1-@xxxxxxxxxxxxxxx :

	> [...] 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.

This is the design I am trying to convey to, please let me know if they
are not correct.

  a) There is one workqueue implementation -- what is today the unbound one --
     and percpu becomes one of its affinity settings rather than a separate
     type. The unbound_* helper names get renamed/removed once they stop
     being unbound-specific. So, `alloc_unbound_pwq()` becomes
     `alloc_pwq` and handle both cases.

  b) There is one pwq path, and alloc_and_link_percpu_pwqs() goes away.

  c) Which pool backs a pwq becomes a property of the attrs, resolved in
     alloc_unbound_pwq(), which hands out either the static percpu pool for
     that CPU or a hashed unbound one.

  d) Both pool types stay -- concurrency management only exists on the percpu
     ones -- so what gets merged is the machinery, not the pools.

  e) this ugly __WQ_PERCPU_POOLS goes away, WQ_PERCPU carries the
     intent, and the unbound path handles WQ_PERCPU directly. WQ_PERCPU
     and WQ_UNBOUND stop being mutually exclusive types and become
     a choice of backing, so the exclusivity check in alloc_workqueue()
     changes meaning or goes away.

Thanks for the guidance here,
--breno