From: Steve Dickson <SteveD@RedHat.com>
To: nfs@lists.sourceforge.net
Subject: NFSD Flow Control Using the TCP Transport
Date: Wed, 19 Mar 2003 10:05:15 -0500 [thread overview]
Message-ID: <3E78872B.5020702@RedHat.com> (raw)
Hello,
There seems to be some issues (probably known) with the flow control
over TCP connections (on an SMP machine) to NFSD. Unfortunately,
the fstress benchmark brings these issues out fairly nicely :-(
This is occurring in a 2.4.20 kernel.
When fstress starts it's stress tests, svc_tcp_sendto() immediately
starts failing
with -EGAINs. Initially, this caused an oops because svc_delete_socket()
was being called twice for the same socket [ which was easily fixed by
checking
for the SK_DEAD bit in svsk->sk_flags], but now the tests just fail.
The problem seems to stem from the fact that the queued memory in
the TCP send buffer (i.e. sk->wmem_queued) is not being released ( i.e
tcp_wspace(sk) becomes negative and never recovers).
Here is what's (appears to be) happening:
Fstress opens one TCP connection and then start sending
multiple nfs ops with different fhandles . The problems start when
a nfs op, with a large responses (like a read), gets 'stuck' in the nfs code
for a few microseconds and in the meantime other nfs ops, with smaller
responses are being processed. With every smaller response, the
sk->wmem_queued value is incremented. Now when the 'stuck' nfs read
tries to send its responses the send buffer is full (i.e.
tcp_memory_free(sk)
in tcp_sendmsg() fails) and after a 30 second sleep (in tcp_sendmsg())
-EAGAIN is returned and the show is over.....
I _guess_ what is suppose to happen is that the queued memory will be
freed (or reclaimed) when a socket buffer is freed (via kfree_skb()).
Which in turn causes the threads waiting for memory (i.e. sleeping
in tcp_sendmsg()) to be woke up via a call to sk->write_space().
But this does not seem to be happening even when the smaller
replies are processed....
Can anyone shed some light on what the heck is going on here
and if there are any patches or solutions or ideas addressing this
problem.
TIA,
SteveD.
-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next reply other threads:[~2003-03-19 15:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-19 15:05 Steve Dickson [this message]
2003-03-20 4:24 ` NFSD Flow Control Using the TCP Transport MINOURA Makoto
2003-03-20 4:43 ` MINOURA Makoto
2003-03-21 20:38 ` Steve Dickson
2003-03-24 2:51 ` MINOURA Makoto
2003-03-24 15:07 ` Steve Dickson
2003-03-25 5:32 ` MINOURA Makoto
2003-03-25 11:33 ` Steve Dickson
2003-03-26 5:07 ` MINOURA Makoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E78872B.5020702@RedHat.com \
--to=steved@redhat.com \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.