Re: why nfs server delay 10ms in nfsd_write()?

[Peter Staubach <staubach@redhat.com>]

Lee Revell wrote:

>On Thu, 2005-05-19 at 08:53 -0400, Peter Staubach wrote:
>  
>
>>There are certainly many others way to get gathering, without adding an
>>artificial delay.  There are already delay slots built into the code 
>>which could
>>be used to trigger the gathering, so with a little bit different 
>>architecture, the
>>performance increases could be achieved.
>>
>>Some implementations actually do write gathering with NFSv3, even.  Is
>>this interesting enough to play with?  I suspect that just doing the 
>>work for
>>NFSv2 is not...
>>    
>>
>
>Also, how do you explain the big performance hit that steve observed?
>Write gathering is supposed to help performance, but it's a big loss on
>his test...
>

Well, a little bit more information about what he is doing would be 
helpful.  I'd
like to better understand the environment and what the traffic from the 
client
looks like.

Write gathering is not a panacea for all of the ills caused by the NFSv2 
WRITE
stable storage requirements.  In fact, if done wrong, it can cause 
performance
regressions, such as those being noticed by Steve.

--

I implemented the write gathering used in Solaris and experimented with
several (many?) different approachs.  Adding a delay in order to allow
subsequent WRITE requests to arrive seems like a good thing, but can
end up just adding latency to the entire process if not done right.

A suggestion might be to use the delay caused by the nfsd_sync() call
and synchronize other WRITE requests around that.  The delay caused by
doing real i/o to the storage subsystem should allow write gathering to
take place, assuming that the client is generating concurrent WRITE
requests.

       ps