Yes I understand its a RPC issue not an NFS issue.
I guess I should have made it clear that I think
that the _RPC_ layer should be able to handle
EAGAINs (using the TCP transport).
The patch you provided does indeed stop the RPC
layer from returning EAGAINs but also stops the flow
of traffic because the sockets with are no longer
being enqueued which in turn means there are no
threads sleeping/waiting (in tcp_sendmsg) when
the svc_write_space routine is called. So once
this flow condition hits, the replys stop which
means the incoming requests also stop and all
the nfsds end up sitting in svc_recv() waiting
for something to do....
0bviously, there is another issue in player here
(which I'm currently debugging), since I do think your
patch make sense....
SteveD.
MINOURA Makoto wrote:
>|> In <[email protected]>
>|> Steve Dickson <[email protected]> wrote:
>
>
>
>>So If I understand what your saying, EAGAINs or partial writes are
>>interpreted
>>as fatal errors. This confuse me. EAGAINs or partial writes are flow
>>control
>>issues not fatal errors. Just like on the client side, shouldn't the
>>thread sleep until there is room? Closing down the socket seems a
>>bit drastic... Or am I missing something?
>>
>>
>
>In general you are right, but as of Linux kNFSd something
>like a flow control is done in the RPC layer.
>
>In kNFSd multiple nfsd threads share a single socket and to
>avoid data mixture a sendto call must be atomic. In order
>to guarantee this the threads sleep in the RPC layer until
>there is enough TCP write space. By doing so EAGAIN can be
>interpreted as something wrong is going on.
>
>But since the free space calculation was wrong this
>assumption was broken. The patch attached in my previous
>mail corrects this.
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
|> In <[email protected]>
|> Steve Dickson <[email protected]> wrote:
> The patch you provided does indeed stop the RPC
> layer from returning EAGAINs but also stops the flow
> of traffic because the sockets with are no longer
> being enqueued which in turn means there are no
> threads sleeping/waiting (in tcp_sendmsg) when
> the svc_write_space routine is called. So once
> this flow condition hits, the replys stop which
> means the incoming requests also stop and all
> the nfsds end up sitting in svc_recv() waiting
> for something to do....
I'm afraid that I do not understand exactly what you are
saying.
We do not start processing a request (enqueue the socket)
before we get enough write space for any single request. So
we do not have to sleep in tcp_sendmsg. This is the
original intention of Linux-2.4.20, not a specific behaviour
to my patch.
--
Minoura Makoto <[email protected]>
Engineering Dept., VA Linux Systems Japan
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
MINOURA Makoto wrote:
>We do not start processing a request (enqueue the socket)
>before we get enough write space for any single request.
>
Right.... This is exactly what is happening. Three or four responses are
*not* being enqueued because there is not enough write space. The
problem I'm seeing is those sockets are never getting re-enqueued.
Your patch is depending on the tcp layer calling svc_write_space()
[when the write space is freed] to start the enqueuing of the sockets.
For some reason that is not happening in my case.....
SteveD.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
|> In <[email protected]>
|> Steve Dickson <[email protected]> wrote:
> Right.... This is exactly what is happening. Three or four responses are
> *not* being enqueued because there is not enough write space. The
> problem I'm seeing is those sockets are never getting re-enqueued.
> Your patch is depending on the tcp layer calling svc_write_space()
> [when the write space is freed] to start the enqueuing of the sockets.
> For some reason that is not happening in my case.....
Hmmm, at least one reason is fixed by our patch, asserting
SOCK_NOSPACE before sleeping for more write space.
--
Minoura Makoto <[email protected]>
Engineering Dept., VA Linux Systems Japan
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs