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

[Tejun Heo <tj@kernel.org>]

Hello, Breno.

Sorry about the delay.

On Fri, Jul 17, 2026 at 09:25:09AM -0700, Breno Leitao wrote:
> 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 don't think we'd deprecate WQ_PERCPU. It'd remain the way to specify on
creation that the workqueue has to be WQ_AFFN_PERCPU.

Also, maybe WQ_AFFN_PERCPU can be more descriptive - WQ_AFFN_CPU_CM for
concurrency-managed CPU scope? Or maybe this shouldn't be packaged into
WQ_AFFN but rather become its own mode field.

> 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?

For concurrency management to work, it would need separate accounting (of
max_active, right?). WQ_PERCPU would indicate that the wq must stay per-cpu
for correctness, and we'd also want to allow concurrency management to
workqueues which want to be percpu for performance reasons but can be
switched into other affinity scopes for isolation, so it should move
together with whether the backend needs concurrency management or not
instead of WQ_PERCPU expressed at creation time.

It kinda sucks that max_active's meaning is different across the boundary
tho. Maybe percpu max_active should be separate into its own field, idk.

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

We can't switch workqueues on / off WQ_BH, but it'd also look a bit silly if
this becomes its own path. Code-shape-wise, I suspect it'd be cleaner if
this also becomes one of the pwq backends like the other two cases but
that's just a gut feel.

>     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?

Again, without thinking too deeploy about it, I think the code would look
better if we unify everything we can.

Thanks.

-- 
tejun