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

["Chuck Lever" <cel@kernel.org>]

On Sun, 13 Sep 2026, Tim Menninger wrote:
>                         unpinned       node0 pinned
>     free_fastpath:     +49,161,373    +119,680,629
>     free_slowpath:     +70,391,872          +8,999
>     sheaf_flush:        +1,582,440     +13,436,760
>     barn_put:             +673,877      +1,596,175
>     barn_put_fail:         +26,374        +223,950
>     barn_get:             +673,860      +1,596,219
>     barn_get_fail:      +1,199,576        +224,090
>     alloc_slowpath:              0               0
>
> So free_slowpath does in fact drop essentially to zero when allocation
> and completion/freeing are kept on the same NUMA node.

Thanks, that settles the remote-free question.


> The dominant slab lock was still heavily contended in that run.
> Filtering it by caller gave:
>
>     2,907,948   __slab_free+0x126
>       269,174   get_partial_node_bulk+0x9c
>       175,965   __refill_objects_node+0x4d0

Set beside the unpinned profile from your Sep 12 mail:

                            unpinned    node0 pinned
    __slab_free            2,845,710       2,907,948
    get_partial_node_bulk    318,458         269,174
    __refill_objects_node    181,842         175,965

The lock profile did not move. free_slowpath fell by four orders
of magnitude and __slab_free took list_lock just as often. So the
list_lock contention is not the remote frees, and it never was!

The counters show where it comes from instead. sheaf_flush rose to
13,436,760 objects, and 13,436,760 / 60 = 223,946, which is your
barn_put_fail. That is the barn-full path in free_to_pcs: once the
node's barn holds MAX_FULL_SHEAVES (10) full sheaves, a put fails,
the spare sheaf is flushed through sheaf_flush_unused and
__kmem_cache_free_bulk, and __slab_free takes list_lock for each
slab in the flush. That route never increments FREE_SLOWPATH,
which is why the counter went quiet while the lock did not. It is
also why sheaf_flush_unused and __kmem_cache_free_bulk never
appeared as callers: perf lock charges the acquisition to
__slab_free on both routes.

barn_get_fail matches barn_put_fail almost exactly, and barn_get
matches barn_put. The barn is a bounded buffer between the CPUs
that allocate nfs_page objects and the rpciod CPUs that free them,
and about 12% of the time it is over- or underflowing.

So the cross-node placement adds roughly 2-4 GB/s of penalty, some
of which is node 0 itself (45 vs 46-47 with balanced CQs), while
the lock profile is unchanged. That points at the per-object cost
of 70M individual remote __slab_free calls, not at list_lock
queueing.

Three numbers you likely already have on disk would help clarify
this... no new runs needed:

- Total and average wait for the list_lock address in the pinned
  run. The unpinned run showed 5.05 min and 90 us average; if the
  pinned run is similar, the lock absorbs the same time whichever
  way the frees go.
- mpstat idle for node 0 in both runs, to tell whether that wait
  is idle time being spent or throughput being lost.
- Throughput for the node 0 / node 0 run that produced the counter
  table above. It is the one configuration missing from your
  throughput table.


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