public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Lee Revell <rlrevell@joe-job.com>
Cc: steve <lingxiang@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"zhangtiger@huawei.com" <zhangtiger@huawei.com>
Subject: Re: why nfs server delay 10ms in nfsd_write()?
Date: Thu, 19 May 2005 08:53:06 -0400	[thread overview]
Message-ID: <428C8C32.2030803@redhat.com> (raw)
In-Reply-To: <1116472423.11327.1.camel@mindpipe>

Lee Revell wrote:

>On Thu, 2005-05-19 at 10:46 +0800, steve wrote:
>  
>
>>i have 2 questions:
>>1.i don't know why do we have to sleep for 10 ms, why not do sync immediately?
>>2.what will happen if we don't sleep for 10ms?
>>when i delete these codes, i get a good result, and the write performace improved from 300KB/s to 18MB/s
>>
>>    
>>
>
>Did you read the comments in the code?
>
>                /*
>                 * Gathered writes: If another process is currently
>                 * writing to the file, there's a high chance
>                 * this is another nfsd (triggered by a bulk write
>                 * from a client's biod). Rather than syncing the
>                 * file with each write request, we sleep for 10 msec.
>                 *
>                 * I don't know if this roughly approximates
>                 * C. Juszak's idea of gathered writes, but it's a
>                 * nice and simple solution (IMHO), and it seems to
>                 * work:-)
>                 */
>  
>

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...

    Thanx...

       ps

  reply	other threads:[~2005-05-19 12:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  2:46 why nfs server delay 10ms in nfsd_write()? steve
2005-05-19  3:08 ` Trond Myklebust
2005-05-19  3:13 ` Lee Revell
2005-05-19 12:53   ` Peter Staubach [this message]
2005-05-19 13:26     ` Trond Myklebust
2005-05-19 13:41       ` Peter Staubach
2005-05-19 13:59     ` Lee Revell
2005-05-19 14:10       ` Peter Staubach
2005-05-19 14:13       ` Avi Kivity
  -- strict thread matches above, loose matches on Subject: below --
2005-05-20 10:44 steve
2005-05-20 13:05 ` Peter Staubach

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=428C8C32.2030803@redhat.com \
    --to=staubach@redhat.com \
    --cc=lingxiang@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    --cc=zhangtiger@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox