From: Breno Leitao <leitao@debian.org>
To: Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, puranjay@kernel.org,
linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Michael van der Westhuizen <rmikey@meta.com>,
kernel-team@meta.com, Chuck Lever <chuck.lever@oracle.com>,
Breno Leitao <leitao@debian.org>
Subject: [PATCH v2 0/5] workqueue: Introduce a sharded cache affinity scope
Date: Fri, 20 Mar 2026 10:56:26 -0700 [thread overview]
Message-ID: <20260320-workqueue_sharded-v2-0-8372930931af@debian.org> (raw)
TL;DR: Some modern processors have many CPUs per LLC (L3 cache), and
unbound workqueues using the default affinity (WQ_AFFN_CACHE) collapse
to a single worker pool, causing heavy spinlock (pool->lock) contention.
Create a new affinity (WQ_AFFN_CACHE_SHARD) that caps each pool at
wq_cache_shard_size CPUs (default 8).
Changes from RFC:
* wq_cache_shard_size is in terms of cores (not vCPU). So,
wq_cache_shard_size=8 means the pool will have 8 cores and their siblings,
like 16 threads/CPUs if SMT=1
* Got more data:
- AMD EPYC: All means are within ~1 stdev of zero. The deltas are
indistinguishable from noise. Shard scoping has no measurable effect
regardless of shard size. This is justified due to AMD EPYC having
11 L3 domains and lock contention not being a problem:
- ARM: A strong, consistent signal. At shard sizes 8 and 16 the mean
improvement is ~7% with relatively tight stdev (~1–2%) at write,
meaning the gain is real and reproducible across all IO engines.
Even shard size 4 shows a solid +3.5% with the tightest stdev
(0.97%).
Reads: Small shard sizes (2, 4) show a slight regression of
~1.3–1.7% (low stdev, so consistent). Larger shard sizes (8, 16)
flip to a modest +1.4% gain, though shard_size=8 reads have high
variance (stdev 2.79%) driven by a single outliers (which seems
noise)
- Sweet spot: Shard size 8 to 16 offers the best overall profile
— highest write gain (6.95%) with the lowest write stdev (1.18%),
plus a consistent read gain (1.42%, stdev 0.70%), no impact on
Intel.
* ARM (NVIDIA Grace - Neoverse V2 - single L3 domain: CPUs 0-71)
┌────────────┬────────────┬─────────────┬───────────┬────────────┐
│ Shard Size │ Write Mean │ Write StDev │ Read Mean │ Read StDev │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 2 │ +0.75% │ 1.32% │ -1.28% │ 0.45% │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 4 │ +3.45% │ 0.97% │ -1.73% │ 0.52% │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 8 │ +6.72% │ 1.97% │ +1.38% │ 2.79% │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 16 │ +6.95% │ 1.18% │ +1.42% │ 0.70% │
└────────────┴────────────┴─────────────┴───────────┴────────────┘
* Intel (AMD EPYC 9D64 88-Core Processor - 11 L3 domains, 8 Cores / 16 vCPUs each)
┌────────────┬────────────┬─────────────┬───────────┬────────────┐
│ Shard Size │ Write Mean │ Write StDev │ Read Mean │ Read StDev │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 2 │ +3.22% │ 1.90% │ -0.08% │ 0.72% │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 4 │ +0.92% │ 1.59% │ +0.67% │ 2.33% │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 8 │ +1.75% │ 1.47% │ -0.42% │ 0.72% │
├────────────┼────────────┼─────────────┼───────────┼────────────┤
│ 16 │ +1.22% │ 1.72% │ +0.43% │ 1.32% │
└────────────┴────────────┴─────────────┴───────────┴────────────┘
---
Changes in v2:
- wq_cache_shard_size is in terms of cores (not vCPU)
- Link to v1: https://patch.msgid.link/20260312-workqueue_sharded-v1-0-2c43a7b861d0@debian.org
---
Breno Leitao (5):
workqueue: fix typo in WQ_AFFN_SMT comment
workqueue: add WQ_AFFN_CACHE_SHARD affinity scope
workqueue: set WQ_AFFN_CACHE_SHARD as the default affinity scope
tools/workqueue: add CACHE_SHARD support to wq_dump.py
workqueue: add test_workqueue benchmark module
include/linux/workqueue.h | 3 +-
kernel/workqueue.c | 110 +++++++++++++++++-
lib/Kconfig.debug | 10 ++
lib/Makefile | 1 +
lib/test_workqueue.c | 277 +++++++++++++++++++++++++++++++++++++++++++++
tools/workqueue/wq_dump.py | 3 +-
6 files changed, 401 insertions(+), 3 deletions(-)
---
base-commit: 1adb306427e971ccac25b19410c9f068b92bd583
change-id: 20260309-workqueue_sharded-2327956e889b
Best regards,
--
Breno Leitao <leitao@debian.org>
next reply other threads:[~2026-03-20 17:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 17:56 Breno Leitao [this message]
2026-03-20 17:56 ` [PATCH v2 1/5] workqueue: fix typo in WQ_AFFN_SMT comment Breno Leitao
2026-03-20 17:56 ` [PATCH v2 2/5] workqueue: add WQ_AFFN_CACHE_SHARD affinity scope Breno Leitao
2026-03-23 22:43 ` Tejun Heo
2026-03-26 16:20 ` Breno Leitao
2026-03-26 19:41 ` Tejun Heo
2026-03-20 17:56 ` [PATCH v2 3/5] workqueue: set WQ_AFFN_CACHE_SHARD as the default " Breno Leitao
2026-03-20 17:56 ` [PATCH v2 4/5] tools/workqueue: add CACHE_SHARD support to wq_dump.py Breno Leitao
2026-03-20 17:56 ` [PATCH v2 5/5] workqueue: add test_workqueue benchmark module Breno Leitao
2026-03-23 14:11 ` [PATCH v2 0/5] workqueue: Introduce a sharded cache affinity scope Chuck Lever
2026-03-23 15:10 ` Breno Leitao
2026-03-23 15:28 ` Chuck Lever
2026-03-23 16:26 ` Breno Leitao
2026-03-23 18:04 ` Chuck Lever
2026-03-23 18:19 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260320-workqueue_sharded-v2-0-8372930931af@debian.org \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=chuck.lever@oracle.com \
--cc=jiangshanlai@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=puranjay@kernel.org \
--cc=rmikey@meta.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox