Re: [PATCH RFC 0/3] Refactor the workqueue allocations

[Tejun Heo]

Hello,

On Tue, Jul 14, 2026 at 04:41:46AM -0700, Breno Leitao wrote:
...
> 1) wqattrs is an unbound concept and apply_workqueue_attrs_locked() rejects
>    non-unbound wqs. Should we leverage wqattrs in per-cpu workqueues as well,
>    so the unification can happen later (apply_workqueue_attrs_locked())?

I'm not sure adding wqattrs to percpu workqueues makes sense. Wouldn't the
shape more be like unbound workqueue subsuming percpu workqueue?

> 2) If percpu becomes a WQ_AFFN_CPU affinity setting, how should max_active be
>    treated? WQ_AFFN_CPU is unbound today, so it would inherit per-node
>    accounting (wq_node_nr_active) and lose percpu's per-cpu max_active
>    (pwq->nr_active).

I think it probably would be better to introduce a separate affinity scope
than modifying WQ_AFFN_CPU. Something which indicates that concurrency
management is in effect and max_active is per-cpu.

> 3) What end state are you aiming for? Keep WQ_PERCPU as a thin flag over
>    unified internals (single install path, per-cpu accounting special-cased)
>    with WQ_UNBOUND staying for now -- or something more radical (the flags gone
>    entirely, percpu purely an affinity value)?

Keeping WQ_PERCPU as a shorthand for specifying the percpu scope makes sense
to me.

Thanks.

-- 
tejun