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

From: Tejun Heo

Date: Mon Aug 03 2026 - 13:58:46 EST


On Mon, Aug 03, 2026 at 09:35:16AM -0700, Breno Leitao wrote:
> 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.

Yeah, this makes sense to me.

Thanks.

--
tejun