diff options
author | Jeff Layton <jlayton@kernel.org> | 2025-04-11 10:22:14 -0400 |
---|---|---|
committer | Chuck Lever <chuck.lever@oracle.com> | 2025-05-11 19:48:26 -0400 |
commit | 18c64378ad85ef00e70f196793ee8901a8aa2fa1 (patch) | |
tree | d36fa9fff02668cd7bcbe7d1dd18557b97e6c25a /tools/perf/scripts/python/export-to-sqlite.py | |
parent | 8c4aae5582cf7901655988809ad94a6f6f2bce63 (diff) |
sunrpc: add info about xprt queue times to svc_xprt_dequeue tracepoint
I've been looking at a problem where we see increased RPC timeouts in
clients when the nfs_layout_flexfiles dataserver_timeo value is tuned
very low (6s). This is necessary to ensure quick failover to a different
mirror if a server goes down, but it causes a lot more major RPC timeouts.
Ultimately, the problem is server-side however. It's sometimes doesn't
respond to connection attempts. My theory is that the interrupt handler
runs when a connection comes in, the xprt ends up being enqueued, but it
takes a significant amount of time for the nfsd thread to pick it up.
Currently, the svc_xprt_dequeue tracepoint displays "wakeup-us". This is
the time between the wake_up() call, and the thread dequeueing the xprt.
If no thread was woken, or the thread ended up picking up a different
xprt than intended, then this value won't tell us how long the xprt was
waiting.
Add a new xpt_qtime field to struct svc_xprt and set it in
svc_xprt_enqueue(). When the dequeue tracepoint fires, also store the
time that the xprt sat on the queue in total. Display it as "qtime-us".
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions