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

[Tejun Heo <tj@kernel.org>]

Hello,

On Sat, May 03, 2025 at 10:28:30AM +0200, Marco Crivellari wrote:
> Hi!
> 
> This series is the follow up of the discussion from:
> 	"workqueue: Always use wq_select_unbound_cpu() for WORK_CPU_UNBOUND."
> 	https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/

Can you please make a summary of the discussion here? Referring to old
thread is useful but it'd be nice to have the rationales laid out in the
patchset - why this is desirable, what is the transition plan and what are
the rationales for it? Also, please include a short summary in the patches.

> 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.
> 	
> 	system_wq renamed in system_percpu_wq, while system_unbound_wq
> 	became system_dfl_wq.

Let's keep the old names for a release or two and trigger printk_once()
warnings about the renames. These are pretty widely used, so I think it
warrants a bit of extra effort.

> 2)  [P 3] Introduction of WQ_PERCPU.
> 
> 	This patch adds a new WQ_PERCPU flag to explicitly request the legacy
> 	per-CPU behavior. WQ_UNBOUND will be removed once the migration is
> 	complete.

I wouldn't call per-cpu behavior legacy. There are plenty of cases that need
per-cpu behavior for correctness and/or performance.

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

Similarly, let's warn about violations and assume the old behavior at first.

> 3)  [P 4] alloc_workqueue() callee should pass explicitly WQ_PERCPU.

Do you mean caller?

> 
> 	This patch ensures that every caller that needs per-cpu workqueue
> 	will explicitly require it, using the WQ_PERCPU flag.

How is 3) different from 2)?

Thanks.

-- 
tejun