Re: [PATCH v2 0/4] Workqueue: rename system workqueue and add WQ_PERCPU

[Tejun Heo <tj@kernel.org>]

Hello, Marco.

On Mon, Jun 09, 2025 at 12:35:31PM +0200, Marco Crivellari wrote:
> === Introduced Changes by this patchset ===
> 
> 1)  [P 1-2] system workqueue rename:
> 
> 		system_wq is a per-CPU workqueue, but his name is not clear.
> 		system_unbound_wq is to be used when locality is not required.
> 
> 		Because of that, system_wq has been renamed in system_percpu_wq,
> 		while system_unbound_wq is now system_dfl_wq.
> 
> 		The old wq are still around, but if used in queue_work(), a pr_warn_once()
> 		will be printed and the wq used is automatically assigned to the new
> 		default (system_dfl_wq or system_percpu_wq).
> 
> 2)  [P 3] Introduction of WQ_PERCPU.
> 
> 		This patch adds the new WQ_PERCPU flag to explicitly require to be per-cpu.
> 
> 		Every alloc_workqueue() caller should use one among WQ_PERCPU or
> 		WQ_UNBOUND. This is actually enforced warning if both or none of them
> 		are present at the same time.
> 
> 		WQ_UNBOUND will be removed in a next release cycle.
> 
> 		Because of that, this patch also adds to every alloc_workqueue() caller
> 		that require it, the new WQ_PERCPU flag.
> 
> 3)  [P 4] WQ_PERCPU documented in workqueue.rst
> 
> 		Added a short section about WQ_PERCPU and a Note under WQ_UNBOUND
> 		mentioning that it will be removed in the future.

Thanks for working on this and the changes generally make sense to me.
However, I think we should try a bit harder to reduce friction with the
affected subsystems. It's a bit unfortunate that we're already at rc1. It
would have been better if the new flags and wq were introduced before rc1.
Oh well, we can manage. How about something like this?

- Separate out patches to add the new flag and wq. Don't add the warnings
  yet. I'll commit these patches to a separate wq branch.

- Split out patches by subsystems. I know this is tedious but think it'd
  still be worth doing. It doesn't have to be completely granular. e.g. We
  know that network changes go through a single tree, so all network changes
  can be in a single patch. Each patch can explain the workqueue changes and
  that the patch can be either routed through the subysstem which would
  require pulling from the above wq branch, or, as the default option, we'd
  be happy to route the patch through the workqueue tree. I can create a
  separate branch to collect the conversion patches that can go through wq
  tree.

- After the next rc1 drops, I can apply the patches to add warnings to the
  -fixes branch and then send them to Linus.

This is a bit more work but would likely produce less friction without
delaying the timeline significantly.

Thanks.

-- 
tejun