All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.