Re: [RFC PATCH 0/2] Add queue_*() functions and prefer per-cpu workqueue and flag

[Tejun Heo]

(cc'ing Breno)

Hello,

On Tue, May 05, 2026 at 06:16:56PM +0200, Marco Crivellari wrote:
> Actually schedule_work() and schedule_work_on() enqueue works using
> system_percpu_wq. The function name doesn't suggest it, on top of that,
> only the per-cpu version is present.

I was hoping to just retire schedule_work[_on]() and let people use e.g.
system_percpu_wq directly. Is that too verbose for casual users?

> Because of that, the following changes are introduced:
> 
> - queue_{bound|unbound}_work() as future replacement of schedule_work()

If we do this, I think "percpu" is a lot clearer than "bound". percpu <->
(nothing) combination would be nice eventually but maybe that's too
confusing now. Does percpu <-> unbound combination sound weird?

...
> The Workqueue API currently do not distinguish between use case where
> locality is important for correctness and where is important for
> efficiency. So introduce WQ_PREFER_PERCPU and wq_prefer_percpu_wq, so
> that works who need to be per-cpu but don't strictly require it, can
> use such workqueue / workqueue flag.

What's requested through WQ_PREFER_PERCPU is simliar to what WQ_AFFN_CPU
does, so that might just work out. The only problem is that WQ_AFFN_CPU will
create nr_cpus workers to populate the per-cpu pods on boot. Maybe that's
not a problem if this gets used widely.

Thanks.

-- 
tejun