From: xuehai zhang <hai@cs.uchicago.edu>
To: "Santos, Jose Renato G" <joserenato.santos@hp.com>
Cc: keahey@mcs.anl.gov, Tim Freeman <tfreeman@mcs.anl.gov>,
xen-devel@lists.xensource.com
Subject: Re: question about disk performance in domU
Date: Mon, 21 Nov 2005 16:41:53 -0600 [thread overview]
Message-ID: <43824D31.4080600@cs.uchicago.edu> (raw)
In-Reply-To: <6C21311CEE34E049B74CC0EF339464B924B51D@cacexc12.americas.cpqcorp.net>
Renato and Tim,
Thank you for your replies.
Is there anyway to flush the dom0 file buffer before running hdparm on domU each time?
Xuehai
Santos, Jose Renato G wrote:
>
>>>-----Original Message-----
>>>From: xen-devel-bounces@lists.xensource.com
>>>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>>>Tim Freeman
>>>Sent: Monday, November 21, 2005 12:45 PM
>>>To: xen-devel@lists.xensource.com
>>>Cc: keahey@mcs.anl.gov; xuehai zhang
>>>Subject: Re: [Xen-devel] question about disk performance in domU
>>>
>>>
>>>So the "Timing buffered disk reads" show much higher
>>>results. I see the DMA zone is larger in domU, but since
>>>this is mapped to a loopback file I'm guessing the physical
>>>disk performance should only be affected by what dom0's DMA
>>>zone is set to on the node running the domU if that is all
>>>that was going on. But dom0 performance seems comparable to
>>>native linux.
>>>
>>>Is this huge "timing buffered disk read" difference
>>>accurate? Does the domU benefit from some other cache of the
>>>loopback file in dom0?
>
>
> Yes. It seems to me that this is the effect of the file buffer
> cache on dom0. hdparm flushes the file cache on domU
> to make sure that there is no data in the file buffer cache
> when measuring device access times (reported as buffered disk
> reads). However when using VBDs mapped to files, the data is
> also cached on dom0 file buffer. Therefore data is not coming
> directly from the device but from dom0 file cache. Note how the
> amount of data that is read in 3 sec increases at each step,
> since data read in previous steps come from dom0 file cache.
>
next prev parent reply other threads:[~2005-11-21 22:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 22:26 question about disk performance in domU Santos, Jose Renato G
2005-11-21 22:41 ` xuehai zhang [this message]
2005-11-21 22:51 ` Adam Heath
2005-11-21 23:58 ` xuehai zhang
-- strict thread matches above, loose matches on Subject: below --
2005-11-21 15:41 xuehai zhang
2005-11-21 20:45 ` Tim Freeman
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=43824D31.4080600@cs.uchicago.edu \
--to=hai@cs.uchicago.edu \
--cc=joserenato.santos@hp.com \
--cc=keahey@mcs.anl.gov \
--cc=tfreeman@mcs.anl.gov \
--cc=xen-devel@lists.xensource.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 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.