From: NeilBrown <neilb@suse.de>
To: "Ramon Schönborn" <RSchoenborn@gmx.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: md device io request split
Date: Thu, 24 Nov 2011 06:30:51 +1100 [thread overview]
Message-ID: <20111124063051.33cdad37@notabene.brown> (raw)
In-Reply-To: <20111123132216.162860@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Wed, 23 Nov 2011 14:22:16 +0100 "Ramon Schönborn" <RSchoenborn@gmx.net>
wrote:
>
> > RAID1 will only limit requests to 4K if the device beneath it is
> > non-contiguous - e.g. a striped array or LVM arrangement were consecutive
> > blocks might be on different devices.
>
> how does it know if a device is non-contiguous? Is there a way to have a dm device "marked" like that or force md to use bigger requests?
> Lets assume a host with about 20 raid1 devices consisting of dm-devices with the mentioned overhead - do you think that not splitting the requests could lead to a noticeable performance improvement?
>
> Thanx for your help,
> Ramon Schönborn
If the device provide a "merge_bvec_fn", then it is assumed to not be
contiguous.
dm always sets this on its devices.
I really have no idea what sort of overhead this creates. You would need to
test it.
I assume you are using dm simply as a partitioning tool with a single linear
mapping per device.
If this is the case it should be safe for testing to remove the line
blk_queue_merge_bvec(md->queue, dm_merge_bvec);
from drivers/md/dm.c and see how that change performance. If you have any dm
targets more simple than a single linear mapping with will almost certainly
cause IO failure at some point so this should only be used for testing.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2011-11-23 19:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 9:36 md device io request split "Ramon Schönborn"
2011-11-23 2:31 ` NeilBrown
2011-11-23 13:22 ` "Ramon Schönborn"
2011-11-23 19:30 ` NeilBrown [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=20111124063051.33cdad37@notabene.brown \
--to=neilb@suse.de \
--cc=RSchoenborn@gmx.net \
--cc=linux-raid@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).