mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v3 0/2] SUNRPC/NFS: limit transport disconnects when cancelling flexfiles I/O
@ 2026-11-06 23:28 Tim Menninger
  2026-11-06 23:28 ` [PATCH v3 1/2] SUNRPC: add request-scoped disconnects when cancelling tasks Tim Menninger
  2026-11-06 23:28 ` [PATCH v3 2/2] NFSv4/flexfiles: limit transport disconnects when cancelling I/O Tim Menninger
  0 siblings, 2 replies; 3+ messages in thread
From: Tim Menninger @ 2026-11-06 23:28 UTC (permalink / raw)
  To: trondmy, anna
  Cc: cel, ebadger, jcurley, jlayton, linux-kernel, linux-nfs, netdev,
	slingappa

This series narrows the transport disconnects performed when flexfiles
cancels I/O for a recalled or revoked layout segment.

Today ff_layout_cancel_io() first cancels matching RPC tasks and then
calls rpc_clnt_disconnect() if any tasks matched. rpc_clnt_disconnect()
operates on the entire rpc_clnt, so for a data server client using
multiple transports it disconnects transports that may have had no I/O
associated with the affected layout segment.

I encountered this while testing pNFS over RPC/RDMA during data server
recovery. Restarting the NFS service on a data server while sustained
direct-read I/O was active could cause repeated reconnect activity and a
large throughput drop. The client-wide disconnect from
ff_layout_cancel_io() amplified the disruption by tearing down otherwise
unaffected transports.

The first patch adds a SUNRPC helper that combines task cancellation with
request-scoped conditional disconnects. Matching tasks are cancelled as
before. A subsequent transport-queue pass marks matching requests
belonging to the same rpc_clnt that remain on the transmit or receive
queues. At release, transmitted requests trigger a conditional disconnect
using rq_connect_cookie.

The marker is consumed under xprt_release()'s existing transport_lock
critical section, so the normal request-release path requires no
additional lock acquisition.

The disconnect state is stored on struct rpc_rqst rather than struct
rpc_task. A task can release one request and later acquire another, so a
task-scoped indication could otherwise be consumed by a successor
request and applied to the wrong transport generation.

The request-marking pass also preserves the rpc_clnt selection used by
rpc_cancel_tasks(). An rpc_xprt may be shared by multiple rpc_clnt
instances, so requests belonging to other clients sharing the same
transport are not marked.

The second patch switches flexfiles to the new helper, preserving its
I/O cancellation behavior while avoiding client-wide transport
disconnects.

Testing:

I applied the following because, without it, the client enters a
recovery livelock before the transport-disconnect behavior can be
observed cleanly:

    https://lore.kernel.org/all/20261105153507.3145077-1-tmenninger@purestorage.com/

I also applied the following fix for a separate frwr_unmap_sync() hang
that the reconnect churn makes easier to trigger:

    https://lore.kernel.org/all/20261106142039.1066437-1-tmenninger@everpuredata.com/

Neither change is a code dependency of this series. Both were present
in the test tree and are recorded in the base-tree metadata below.

As a control experiment, I also tested skipping the
ff_layout_cancel_io() task-cancellation and client-disconnect path
entirely for RPC/RDMA. Doing so eliminates the reconnect pathology. This
shows that the pathology depends on the cancellation/disconnect path
introduced by commit b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the
layout is recalled or revoked"), but simply opting RPC/RDMA out of that
behavior would also remove the cancellation that is intended to drain
I/O associated with a recalled or revoked layout segment.

This series instead preserves that cancellation while limiting transport
disconnects to matching requests that remain in flight.

I have repeated the data-server restart test many times and the behavior
is consistent. The counters below are intentionally collected after the
restart event, once throughput has partially recovered and the client has
entered the post-recovery state in which it remains until the workload
completes.

This distinction matters because some transport activity during the
data-server restart itself is expected. The problem addressed here is
the continued reconnect activity after that transition has completed:
once recovery has settled, the client should not continue cycling
otherwise healthy RPC/RDMA connections.

Over approximately 30-second post-recovery sampling windows, RPC/RDMA
disconnect events fall from 1,965 to 276 and connect events from 1,964
to 277, approximately a 7.1-fold reduction. Read throughput improves
from approximately 0.4-1.1 GB/s to 1.9-2.2 GB/s.

The sunrpc:xprt_disconnect_force count reaches zero, but conditional
disconnects do not emit that tracepoint. The RPC/RDMA event counts
therefore provide the more direct comparison of transport activity.

Before (throughput: approximately 0.4-1.1 GB/s):

     Performance counter stats for 'system wide':

                 1,964      rpcrdma:xprtrdma_connect
                 1,965      rpcrdma:xprtrdma_disconnect
                 2,685      sunrpc:xprt_disconnect_force

          30.018975301 seconds time elapsed

After (throughput: approximately 1.9-2.2 GB/s):

     Performance counter stats for 'system wide':

                   277      rpcrdma:xprtrdma_connect
                   276      rpcrdma:xprtrdma_disconnect
                     0      sunrpc:xprt_disconnect_force

          30.048495495 seconds time elapsed

---
Changes in v3:
- Protect rq_disconnect_on_release with transport_lock and consume it
  in xprt_release()'s existing critical section, removing the additional
  queue_lock acquisition from the normal request-release path.
- Factor out xprt_conditional_disconnect_locked() to preserve the
  connection-cookie check without reacquiring transport_lock.
- Add a read barrier on the marked-request release path to order the
  dequeue fast-path runstate checks before reading rq_ntrans and
  rq_connect_cookie.

v2: https://lore.kernel.org/all/20261105020249.2607367-1-tmenninger@purestorage.com/

Changes in v2:
- Rebase onto v7.4-rc1.
- Adapt to the device-ID-aware ff_layout_cancel_io() interface,
  preserving device-node reference cleanup.
- No functional changes to the SUNRPC implementation.

v1: https://lore.kernel.org/all/20260924204525.3381590-1-tmenninger@everpuredata.com/

Tim Menninger (2):
  SUNRPC: add request-scoped disconnects when cancelling tasks
  NFSv4/flexfiles: limit transport disconnects when cancelling I/O

 fs/nfs/flexfilelayout/flexfilelayout.c |   7 +-
 include/linux/sunrpc/sched.h           |   4 +
 include/linux/sunrpc/xprt.h            |   5 ++
 net/sunrpc/clnt.c                      |  94 ++++++++++++++++++----
 net/sunrpc/sunrpc.h                    |   8 ++
 net/sunrpc/xprt.c                      | 107 +++++++++++++++++++++++--
 6 files changed, 198 insertions(+), 27 deletions(-)


base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
prerequisite-patch-id: 2e8f35e38c760c42d04307b131ce55f80df66fef
prerequisite-patch-id: e7030ad56461efdd80f97ab1e0790fd4593805a7
-- 
2.53.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-11-06 23:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-06 23:28 [PATCH v3 0/2] SUNRPC/NFS: limit transport disconnects when cancelling flexfiles I/O Tim Menninger
2026-11-06 23:28 ` [PATCH v3 1/2] SUNRPC: add request-scoped disconnects when cancelling tasks Tim Menninger
2026-11-06 23:28 ` [PATCH v3 2/2] NFSv4/flexfiles: limit transport disconnects when cancelling I/O Tim Menninger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®