From: Andy <genanr@emsphone.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: multipath performance
Date: Mon, 28 Jan 2008 15:52:36 -0600 [thread overview]
Message-ID: <20080128215236.GA13857@thumper2> (raw)
In-Reply-To: <20080125015938.GB28785@us.ibm.com>
On Thu, Jan 24, 2008 at 05:59:39PM -0800, malahal@us.ibm.com wrote:
> Andy [genanr@emsphone.com] wrote:
> > I did some basic dd tests to get an idea of the speed of multipath vs
> > individual devices, some of the numbers seem not to make sense.
> >
> > I ran several test with dd, 4 at a time reading different parts of the
> > device.
> >
> > multibus - round robin among paths rr_min_io=1, 4 paths
> > individual - each dd going to a separate path
> >
> > dd with iflag=direct
> > multibus : 120 MB/s
> > individual : 115 MB/s
> >
> > dd without direct
> > multibus : 44MB/s (why is this so bad)
> > individual : 160MB/s (why is this so good)
> >
> > Why is multibus without direct the worst, yet individual devices without
> > direct is the fastest. And why doesn't multibus perform about the same as
> > going to the individual devices (25% performance hit using multibus)?
>
> I am assuming that you are only reading from the device based on your
> iflag. When you do O_DIRECT, you inherently disable read-ahead. Also
> note that the read-ahead benefit would be insignificant as you increase
> the block size.
>
> without direct I/O, you end up with very big I/O's in individual mode.
> Same can't be said in multibus mode as it tries to send small I/O's
> (actually bio's) on different paths and it makes the system not to merge
> any adjacent requests.
Is there any way (yet) to increase the bio size? It would be nice if
individual paths could perform large I/O's when needed.
Andy
prev parent reply other threads:[~2008-01-28 21:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-23 16:38 multipath performance Andy
2008-01-25 1:59 ` malahal
2008-01-28 21:52 ` Andy [this message]
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=20080128215236.GA13857@thumper2 \
--to=genanr@emsphone.com \
--cc=dm-devel@redhat.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.