Re: [PATCH v5 0/2] workqueue: Make WQ_UNBOUND the default behavior

[Tejun Heo]

Hello, Marco.

On Mon, Nov 02, 2026 at 12:00:45PM +0100, Marco Crivellari wrote:
> This default is suboptimal: most workloads benefit from unbound queues,
> allowing the scheduler to place worker threads where they're needed and
> reducing noise when CPUs are isolated.

I think this is an overstatement. Maybe just say that we're transitioning
to unbound as the default because, while some users benefit from the
strict affinity and concurrency management that per-CPU workqueues
provide, for a lot of users they don't matter and they put significant
restrictions on what the scheduler can do with the work items. Unbound
workqueues now have non-strict (soft) affinity scopes, so they don't lose
all the locality benefits while giving the scheduler more flexibility,
which helps system-level concerns such as power management and isolation.

Can you rebase the series onto wq/for-7.5? 1/2 doesn't apply there.
a23c7afbc587 ("workqueue: Add support for real-time workers") added a
WQ_RT check to __alloc_workqueue() right after the WQ_BH block. The new
defaulting block has to come before that check, or alloc_workqueue() with
WQ_RT and no WQ_UNBOUND warns and fails instead of becoming unbound. The
WQ_RT comment in include/linux/workqueue.h says "valid only with
WQ_UNBOUND", which may want updating too, maybe to something like
"invalid with WQ_PERCPU".

- 1/2: Can you update the description the same way?

  The WQ_POWER_EFFICIENT comment in include/linux/workqueue.h still opens
  with "Per-cpu workqueues are generally preferred because they tend to
  show better performance thanks to cache locality", which now contradicts
  the change. A similar sentence is in the workqueue.power_efficient entry
  in Documentation/admin-guide/kernel-parameters.txt and in the
  WQ_POWER_EFFICIENT_DEFAULT help in kernel/power/Kconfig. Can you update
  them too? While at it, the paragraph the patch edits is left with short
  lines and can be reflowed.

  In the new comment above the defaulting block, "Do this before
  computing wq_size and before WQ_POWER_EFFICIENT can drop WQ_PERCPU",
  "this" doesn't refer to anything and the comment doesn't say why the
  order matters. Maybe note that the WQ_POWER_EFFICIENT override would
  otherwise drop WQ_PERCPU and hide a caller passing both WQ_PERCPU and
  WQ_UNBOUND from the warning?

- 2/2: Saying that WQ_PERCPU is implied is enough. There's no need to
  list it as an allowed flag, so "WQ_HIGHPRI is the only allowed
  additional flag" can stay with "WQ_PERCPU is implied" added.

Thanks.

--
tejun