summaryrefslogtreecommitdiff
path: root/scripts
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2025-01-02 20:00:01 -0500
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-02-08 09:58:12 +0100
commit31b3e5ce9f79d2a41808f53f38c5d590cebb2c73 (patch)
tree9640e0d5f987ec9eb44071cecde00431c5eb5005 /scripts
parent260cbf9927138ccd2386d2c0cfa307b70b8b6398 (diff)
downloadlinux-31b3e5ce9f79d2a41808f53f38c5d590cebb2c73.tar.gz
linux-31b3e5ce9f79d2a41808f53f38c5d590cebb2c73.tar.bz2
linux-31b3e5ce9f79d2a41808f53f38c5d590cebb2c73.zip
Revert "SUNRPC: Reduce thread wake-up rate when receiving large RPC messages"
commit 966a675da844f1a764bb44557c21561cc3d09840 upstream. I noticed that a handful of NFSv3 fstests were taking an unexpectedly long time to run. Troubleshooting showed that the server's TCP window closed and never re-opened, which caused the client to trigger an RPC retransmit timeout after 180 seconds. The client's recovery action was to establish a fresh connection and retransmit the timed-out requests. This worked, but it adds a long delay. I tracked the problem to the commit that attempted to reduce the rate at which the network layer delivers TCP socket data_ready callbacks. Under most circumstances this change worked as expected, but for NFSv3, which has no session or other type of throttling, it can overwhelm the receiver on occasion. I'm sure I could tweak the lowat settings, but the small benefit doesn't seem worth the bother. Just revert it. Fixes: 2b877fc53e97 ("SUNRPC: Reduce thread wake-up rate when receiving large RPC messages") Cc: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions