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

[Breno Leitao]

On Tue, May 05, 2026 at 10:18:49AM -1000, Tejun Heo wrote:
> (cc'ing Breno)

Thanks!

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

I think schedule_work() doesn't help much, and makes the system a bit harder to
understand. When I started reading this code, I would have preferred to see
queue_work(system_percpu_wq, work) instead of schedule_work(work).

In fact, I suspect this patchset exists partly because we have the
schedule_work() helper.

Would this proposal exist if schedule_work() had never been added?

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

Would percpu <-> global sound less weird?

> > The Workqueue API currently do not distinguish between use case where
> > locality is important for correctness and where is important for
> > efficiency.

If you enqueue work to system_unbound_wq with the default affinitization, you
already get locality (WQ_AFFN_CACHE groups CPUs sharing the same LLC). This is
the way to say that locality is important for efficiency, anbd the WQ_AFFN_CPU
is the way to specify that locality is important for correctness. 

On top of that, WQ_AFFN_SYSTEM is a way to specify that locality is not
necessary at all.

Also, how WQ_PREFER_PERCPU behaves differently from WQ_AFFN_CPU?

Thanks for the RFC,
--breno