[PATCH RFC 0/3] Refactor the workqueue allocations
From: Breno Leitao
Date: Tue Jul 14 2026 - 07:42:13 EST
POC for Tejun's idea to unify the per-cpu and unbound workqueues, as
suggested in http://lkml.kernel.org/r/ak569WYSm3ygKl1-@xxxxxxxxxxxxxxx
This series only unifies the allocation part (alloc_pwq()). It makes
alloc_pwq() a single allocator that returns a pwq backed by either a static
per-cpu pool (get_percpu_pool) or an unbound pool (get_unbound_pool), reusing
the existing static per-cpu pools. The install/link path is unchanged and all
patches are behavior-neutral. This sets things up to unify the install side
later.
Is this the right direction?
Questions to follow up:
1) wqattrs is an unbound concept and apply_workqueue_attrs_locked() rejects
non-unbound wqs. Should we leverage wqattrs in per-cpu workqueues as well,
so the unification can happen later (apply_workqueue_attrs_locked())?
2) If percpu becomes a WQ_AFFN_CPU affinity setting, how should max_active be
treated? WQ_AFFN_CPU is unbound today, so it would inherit per-node
accounting (wq_node_nr_active) and lose percpu's per-cpu max_active
(pwq->nr_active).
3) What end state are you aiming for? Keep WQ_PERCPU as a thin flag over
unified internals (single install path, per-cpu accounting special-cased)
with WQ_UNBOUND staying for now -- or something more radical (the flags gone
entirely, percpu purely an affinity value)?
Tests:
1) I've tested this on x86 and arm64, with regular tests
2) I've hacked up a workqueue test suite, which has a bunch of tests,
and this is what I am using to test these changes:
https://github.com/leitao/wqtest
Thanks,
-breno
Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
---
Breno Leitao (3):
workqueue: introduce alloc_pwq()
workqueue: allocate percpu pwqs through alloc_pwq()
workqueue: factor out alloc_and_link_percpu_pwqs()
kernel/workqueue.c | 96 ++++++++++++++++++++++++++++++++++--------------------
1 file changed, 60 insertions(+), 36 deletions(-)
---
base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474
change-id: 20260709-tejun1-c2aaf36f54a4
Best regards,
--
Breno Leitao <leitao@xxxxxxxxxx>