From: Mustafa Mesanovic <mume@linux.vnet.ibm.com>
To: Neil Brown <neilb@suse.de>
Cc: dm-devel@redhat.com, akpm@linux-foundation.org,
snitzer@redhat.com, linux-kernel@vger.kernel.org,
heiko.carstens@de.ibm.com, cotte@de.ibm.com,
ehrhardt@linux.vnet.ibm.com
Subject: Re: [RFC][PATCH] dm: improve read performance
Date: Mon, 27 Dec 2010 13:23:12 +0100 [thread overview]
Message-ID: <201012271323.13406.mume@linux.vnet.ibm.com> (raw)
In-Reply-To: <20101227225459.5a5150ab@notabene.brown>
On Mon December 27 2010 12:54:59 Neil Brown wrote:
> On Mon, 27 Dec 2010 12:19:55 +0100 Mustafa Mesanovic
>
> <mume@linux.vnet.ibm.com> wrote:
> > From: Mustafa Mesanovic <mume@linux.vnet.ibm.com>
> >
> > A short explanation in prior: in this case we have "stacked" dm devices.
> > Two multipathed luns combined together to one striped logical volume.
> >
> > I/O throughput degradation happens at __bio_add_page when bio's get
> > checked upon max_sectors. In this setup max_sectors is always set to 8
> > -> what is 4KiB.
> > A standalone striped logical volume on luns which are not multipathed do
> > not have the problem: the logical volume will take over the max_sectors
> > from luns below.
> >
> > Same happens with luns which are multipathed -> the multipathed targets
> > have the same max_sectors as the luns below.
> >
> > So "magic" happens only when target has no own merge_fn and below lying
> > devices
> > have a merge function -> we got then max_sectors=PAGE_SIZE >> 9.
> > This patch prevents that max_sectors will be set to PAGE_SIZE >> 9.
> > Instead it will use the minimum max_sectors value from below devices.
> >
> > Using the patch improves read I/O up to 3x. In this specific case from
> > 600MiB/s up to 1800MiB/s.
>
> and using this patch will cause IO to fail sometimes.
> If an IO request which is larger than a page crosses a device boundary in
> the underlying e.g. RAID0, the RAID0 will return an error as such things
> should not happen - they are prevented by merge_bvec_fn.
>
> If merge_bvec_fn is not being honoured, then you MUST limit requests to a
> single entry iovec of at most one page.
>
> NeilBrown
>
Thank you for that hint, I will try to write a merge_bvec_fn for dm-stripe.c
which solves the problem, if that is ok?
Mustafa Mesanovic
> > Signed-off-by: Mustafa Mesanovic <mume@linux.vnet.ibm.com>
> > ---
> >
> > dm-table.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-2.6/drivers/md/dm-table.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/md/dm-table.c 2010-12-23 13:49:18.000000000
> > +0100 +++ linux-2.6/drivers/md/dm-table.c 2010-12-23 13:50:22.000000000
> > +0100 @@ -518,7 +518,7 @@
> >
> > if (q->merge_bvec_fn && !ti->type->merge)
> >
> > blk_limits_max_hw_sectors(limits,
> >
> > - (unsigned int) (PAGE_SIZE >> 9));
> > + q->limits.max_sectors);
> >
> > return 0;
> >
> > }
> > EXPORT_SYMBOL_GPL(dm_set_device_limits);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2010-12-27 12:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 11:19 [RFC][PATCH] dm: improve read performance Mustafa Mesanovic
2010-12-27 11:54 ` Neil Brown
2010-12-27 12:23 ` Mustafa Mesanovic [this message]
2011-03-07 10:10 ` Mustafa Mesanovic
2011-03-08 2:21 ` [PATCH v3] dm stripe: implement merge method Mike Snitzer
2011-03-08 10:29 ` Mustafa Mesanovic
2011-03-08 16:48 ` Mike Snitzer
2011-03-10 14:02 ` Mustafa Mesanovic
2011-03-12 22:42 ` Mike Snitzer
2011-03-14 11:54 ` Mustafa Mesanovic
2011-03-14 14:33 ` Mike Snitzer
2011-03-16 20:21 ` [PATCH v4] " Mike Snitzer
2011-03-17 5:12 ` [RFC][PATCH] dm: improve read performance Nikanth Karthikesan
2011-03-17 13:08 ` Mike Snitzer
2011-03-18 4:59 ` Nikanth Karthikesan
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=201012271323.13406.mume@linux.vnet.ibm.com \
--to=mume@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=cotte@de.ibm.com \
--cc=dm-devel@redhat.com \
--cc=ehrhardt@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=snitzer@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.