All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael <oldmoonster@gmail.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Greg Banks <gnb@sgi.com>, Peter Staubach <staubach@redhat.com>,
	nfs@lists.sourceforge.net
Subject: Re: can anyone explain this state?
Date: Thu, 18 Aug 2005 21:41:03 +0800	[thread overview]
Message-ID: <43048FEF.5020402@gmail.com> (raw)
In-Reply-To: <1124324316.8347.79.camel@lade.trondhjem.org>

Trond Myklebust wrote:

>to den 18.08.2005 Klokka 09:51 (+1000) skreiv Greg Banks:
>
>  
>
>>Trond, your comments also apply for READs with rsize<PAGE_SIZE; 2.4
>>will do sync reads on the wire in this case.  The performance drop
>>is not as dramatic as with writes because the server is doing its own
>>local readahead, which can't happen for writes, but there's still
>>a performance drop due to lack of parallelism on the wire.
>>    
>>
>
>Yes, however that only affects the first time the file is read.
>The rather dramatic increase in performance between the first read and
>subsequent attempts may almost certainly be attributed to caching, as
>Peter pointed out.
>
>Note: readahead too may cause an extra performance hit when the reads
>are synchronous: if the kernel schedules more readahead than your
>process actually wants to use, this may force your process to wait for
>_all_ those reads to complete (since said process is responsible for
>actually putting each synchronous read on the wire).
>In the large rsize case, when doing asynchronous reads, this is not the
>case. Your process will wait only on those pages it actually uses.
>
>Cheers,
>  Trond
>
>
>  
>
Sorry, Trond and all, I don't know how can your answer solve my 
problem... As I am newbie, could you explain directly against my question?

========================================================================
Yes, I know it should be cache related, but you can see it took me
more than 1 minute at the first time copy 100Mfile from nfs server,
but suddenly the second time took 4 second.
How can the cache result to this? NFS client cache ability? ok, if it
is, that means NFS client could cache at least 90M data of 100M, then,
how to explain the last 2 copies?  with rsize=8k,first time copy 100M
file took 9 seconds, but the second time took 7 seconds, if cache work
as great as rsize=1k, why not the second time copy take less than 1
second?
========================================================================

Thanks again!

Michael



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-08-18 18:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-17 11:13 can anyone explain this state? Michael
2005-08-17 12:02 ` Trond Myklebust
2005-08-17 12:26   ` Peter Staubach
2005-08-17 12:31     ` Peter Staubach
2005-08-17 12:39     ` Trond Myklebust
2005-08-17 13:39       ` Michael
2005-08-17 14:40         ` Peter Staubach
2005-08-17 14:50           ` Michael
2005-08-17 23:51       ` Greg Banks
2005-08-18  0:18         ` Trond Myklebust
2005-08-18 13:41           ` Michael [this message]
2005-08-18 14:02             ` Trond Myklebust

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=43048FEF.5020402@gmail.com \
    --to=oldmoonster@gmail.com \
    --cc=gnb@sgi.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=staubach@redhat.com \
    --cc=trond.myklebust@fys.uio.no \
    /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.