Re: [PATCH RFC 6/8] SUNRPC: Reduce rpciod workqueue contention

[Chuck Lever]

On Fri, 4 Sep 2026, Tim Menninger wrote:
> With your v2 applied, all-local windows fall to roughly 24-28 GB/s while
> split windows sustain ~46 GB/s.

So on your system the interrupt pinning I suggested would put every
mount into the "slow" placement.

(Pinning completion vectors to the local node still helps where the
dominant cost is cross-socket reply traffic, but your data says that
on your configuration, with this series applied, spreading the CQ
handlers across both sockets matters more than keeping them local).

> So the CQ allocation determines whether the regression is exposed, but
> mainline is insensitive to that placement. The series introduces the
> performance sensitivity.

Agreed. What it does not yet tell us is which part of the series.

Now that you have a reliable way to force an all-local window,
would you run these on top of 940de590b839, each in the all-local
placement:

1. Patches 1-2 only (the XID and recv_lock changes).

2. Patches 3-8 only (WQ_SYSFS, workqueue_set_affn_scope, and the
   three scope changes).

3. The full v2 series, with all three workqueues set to
   cache_shard at once:

     for wq in rpciod xprtiod nfsiod; do
         echo cache_shard > /sys/bus/workqueue/devices/$wq/affinity_scope
     done

If 1 reproduces the slow state on its own, the scope patches are
not the cause and the question becomes why removing queue_lock
contention makes node 0 concentration visible. If only 2
reproduces it, the scope change is the cause and 3 should recover
it.

Also: per-node CPU utilization in a good run and a bad run, e.g.
mpstat -P ALL 1 for a few seconds, or the per-CPU lines from
/proc/stat. Your perf capture showed a lot of idle CPU, so I
would like to know whether node 0 is saturated while node 1
sleeps, or whether both are idle but completions are serializing.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)