From: Chuck Lever <cel@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: jiangshanlai@gmail.com, linux-kernel@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v2] workqueue: Automatic affinity scope fallback for single-pod topologies
Date: Thu, 5 Feb 2026 18:29:28 -0500 [thread overview]
Message-ID: <e1a3c970-e1c0-4ed8-8b81-1d35f00d9c0b@kernel.org> (raw)
In-Reply-To: <aYUVVuIidMpuYy3j@slm.duckdns.org>
On 2/5/26 5:10 PM, Tejun Heo wrote:
> Hello, Chuck.
>
> On Wed, Feb 04, 2026 at 09:49:11PM -0500, Chuck Lever wrote:
>> +static bool __init cpus_share_cluster(int cpu0, int cpu1)
>> +{
>> + return cpumask_test_cpu(cpu0, topology_cluster_cpumask(cpu1));
>> +}
>
> Cluster boundary == core boundary for a lot of CPUs. I don't think this is
> going to work.
Fair enough; WQ_AFFN_CLUSTER is not a reliable intermediate level.
On x86 cpu_clustergroup_mask() returns cpu_l2c_shared_mask(), which
is per-core on many chips. The arm64 cpu_clustergroup_mask() has a
similar collapse: when cluster_sibling spans the coregroup, it falls
back to SMT siblings. And the generic fallback in topology.h is
cpumask_of(cpu).
I was hoping it would be a proper intermediate sharding scope.
> Here are a couple options:>
> - Introduce an affinity level which splits CACHE according to some
> adjustable heuristics.
>
> - Make the NFS workqueue default to WQ_AFFN_CORE (or maybe switch based on
> some heuristics) or switch to a per-cpu workqueue.
The issue I see is that the contention isn't confined to a single
workqueue. In the NFS-over-RDMA I/O paths, at least four unbound
workqueues are in the hot path:
- rpciod (WQ_UNBOUND) in net/sunrpc/sched.c -- core
RPC task wake-up on every completion
- xprtiod (WQ_UNBOUND) in net/sunrpc/xprt.c --
transport cleanup and receive processing
- nfsiod (WQ_UNBOUND) in fs/nfs/inode.c -- direct
write and local I/O completion
- svcrdma_wq (WQ_UNBOUND) in svc_rdma.c -- send
context and write info release on every RDMA
completion
These span three subsystems and maintainers. Other RDMA ULPs (iSER,
SRP target, kSMBd) have their own unbound workqueues with the same
exposure. Tuning each one individually is fragile, and any new
WQ_UNBOUND workqueue added to these paths inherits the degenerate
default behavior.
Even on platforms with a large core-to-pod ratio, pool lock contention
is going to be a significant problem when WQ pools are shared by more
than a handful of cores.
I don't have access to the kind of hardware needed to deeply test
sharding ideas, so I'll drop this patch for now and simply set boot
command line options on all my systems.
--
Chuck Lever
prev parent reply other threads:[~2026-02-05 23:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 2:49 Chuck Lever
2026-02-05 22:10 ` Tejun Heo
2026-02-05 23:29 ` Chuck Lever [this message]
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=e1a3c970-e1c0-4ed8-8b81-1d35f00d9c0b@kernel.org \
--to=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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
Powered by JetHome