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

[Breno Leitao <leitao@debian.org>]

On Thu, Jul 16, 2026 at 09:22:50AM -1000, Tejun Heo wrote:
> 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.

Oh, now I see what you mean, I was heading the wrong way. Thanks for the
clarification, that makes total sense.

So: add a PERCPU wq_affn_scope and back it strictly per-CPU, rather than
reusing WQ_AFFN_CPU. Something like:

    enum wq_affn_scope {
            ...
  +         WQ_AFFN_PERCPU,         /* one pod per CPU, backed by the per-cpu pool */

and move the per-cpu workqueue users onto WQ_AFFN_PERCPU. With that, the
unbound install path (apply_wqattrs and the per-cpu, replaceable pwqs) can
point a pwq at a per-cpu pool, so one mechanism serves both. Then move
all the WQ_PERCPU users to WQ_AFFN_PERCPU, and eventually deprecate
WQ_PERCPU ?

I have this working as a prototype: WQ_PERCPU selects the scope and forces
strict affinity, and it boots with every percpu wq created through the
new path. 

A few things I'd like your read on:

    1) Percpu workqueues keep the WQ_PERCPU flag (I don't switch them to
       WQ_UNBOUND when they move onto the WQ_AFFN_PERCPU scope), so per-cpu
       accounting falls out of the existing !WQ_UNBOUND checks. do you
       have any preference here, or should percpu become purely an
       affn_scope value with accounting decoupled from the flag?

    2) What about WQ_BH? Can we keep it on the direct per-cpu path (softirq
       context) for now?

    3) Routing percpu through apply_wqattrs pulls in unbound-only assumptions
       (unbound_attrs allocation, and the CPU-hotplug fixups in
       workqueue_online_cpu()/workqueue_offline_cpu() that gate on
       unbound_attrs) that now have to learn about the percpu scope.

       Do you prefer teaching that shared path about WQ_AFFN_PERCPU, or would
       you rather percpu keep a lighter install path (closer to the current
       WQ_PERCPU direct path), if that's feasible?

Thanks for the guidance,
--breno