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

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