From: Gerd Hoffmann <kraxel@suse.de>
To: Gerd Hoffmann <kraxel@suse.de>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: [patch] Add support for barriers to blk{back,front} drivers.
Date: Wed, 25 Oct 2006 18:52:16 +0200 [thread overview]
Message-ID: <453F9640.1020505@suse.de> (raw)
In-Reply-To: <453CB53F.8060908@suse.de>
Gerd Hoffmann wrote:
> Ian Pratt wrote:
>> I'd certainly be interested to see some benchmarks with and without the
>> barrier support in blkfront/back.
>
> I'll go run some ...
I did some bonnie++ runs, each test three times. Complete set of
results, also the scripts I've used to run stuff, are at
http://www.suse.de/~kraxel/bb/. Handle the scripts with care, there is
a mkfs call in there ;)
I've picked two numbers (sequential block writes, sequential file
creation) which should have a bunch barrier requests for journal updates.
Machine is a intel devel box with hyperthreading, 1GB of memory, sata
disk. I've used the ext3 filesystem, freshly created on a lvm volume,
mounted with barrier={0,1} and data=journal (to stress journaling and
barriers ...).
Legend:
wce0 - write cache enable = off (hdparm -W0 /dev/sda)
wce1 - write cache enable = on (hdparm -W1 /dev/sda)
barrier0 - barriers off (mount -o barrier=0)
barrier1 - barriers on
Here are the dom0 results:
name blkout create
---------------------------------------
dom0-wce0-barrier1 12614 1841
12598 975
12575 1102
dom0-wce0-barrier0 12656 1320
12569 1629
12669 1313
dom0-wce1-barrier1 18457 2801
18395 3316
18560 2948
dom0-wce1-barrier0 19224 3190
18880 3079
19121 3555
With write caching disabled barriers don't make a big difference, it's
in the noise. Not surprising. With write caching enabled barriers make
things a bit slower. But keep in mind that journaling filesystems can
NOT work reliable without barriers when write caching is enabled. The
small performance penalty simply is the price to have to pay for
filesystem integrity. The other way to make sure the journaling works
ok is to disable write caching. As you can see this costs even more
performance.
domU results (guest with 256 MB memory, separate table due to the
results not being directly comparable with the dom0 ones).
name blkout create
---------------------------------------
domU-wce0-barrier1 9247 866
9167 1265
9591 1131
domU-wce0-barrier0 9413 882
9414 1082
9113 942
domU-wce1-barrier1 21134 4428
19782 3507
19813 3810
domU-wce1-barrier0 20065 3411
20451 4342
20312 4672
Look simliar, but a bit more noisy, so there isn't a clear difference
visible for barriers being on/off ...
cheers,
Gerd
--
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg
next prev parent reply other threads:[~2006-10-25 16:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-23 11:42 [patch] Add support for barriers to blk{back, front} drivers Ian Pratt
2006-10-23 12:27 ` [patch] Add support for barriers to blk{back,front} drivers Gerd Hoffmann
2006-10-25 16:52 ` Gerd Hoffmann [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-10-30 12:15 [patch] Add support for barriers to blk{back, front} drivers Ian Pratt
2006-10-30 12:43 ` [patch] Add support for barriers to blk{back,front} drivers Gerd Hoffmann
2006-11-08 15:38 ` Gerd Hoffmann
2006-11-09 1:04 ` [patch] Add support for barriers to blk{back, front} drivers Ian Pratt
2006-11-09 1:15 ` John Levon
2006-11-09 9:00 ` [patch] Add support for barriers to blk{back,front} drivers Keir Fraser
2006-11-09 12:48 ` Gerd Hoffmann
2006-11-09 13:47 ` Keir Fraser
2006-11-09 14:15 ` Gerd Hoffmann
2006-10-27 13:46 [patch] Add support for barriers to blk{back, front} drivers Ian Pratt
2006-10-30 8:21 ` [patch] Add support for barriers to blk{back,front} drivers Gerd Hoffmann
2006-10-20 8:38 [patch] Add support for barriers to blk{back, front} drivers kraxel
2006-10-20 20:35 ` Ian Pratt
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=453F9640.1020505@suse.de \
--to=kraxel@suse.de \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--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.