From: Alasdair G Kergon <agk@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>,
Ming Lei <ming.lei@canonical.com>,
Oleg@redhat.com, Joshua Morris <josh.h.morris@us.ibm.com>,
Alasdair G Kergon <agk@redhat.com>,
Lars Ellenberg <drbd-dev@lists.linbit.com>,
Philip Kelleher <pjk1939@linux.vnet.ibm.com>,
Christoph Hellwig <hch@lst.de>,
Christoph Hellwig <hch@infradead.org>,
Overstreet <kent.overstreet@gmail.com>,
Nitin Gupta <ngupta@vflare.org>, Jens Axboe <axboe@kernel.dk>,
Al@redhat.com, Drokin <oleg.drokin@intel.com>,
Viro <viro@zeniv.linux.org.uk>,
Dave Chinner <dchinner@redhat.com>, Ming Lin <mlin@kernel.org>,
Kent@redhat.com, Andreas Dilger <andreas.dilger@intel.com>,
Geoff Levand <geoff@infradead.org>, Jiri Kosina <jkosina@suse.cz>,
lkml <linux-kernel@vger.kernel.org>, Jim Paris <jim@jtan.com>,
Minchan Kim <minchan@kernel.org>, Dongsu Park <dpark@posteo.net>,
drbd-user@lists.linbit.com
Subject: Re: [Drbd-dev] [dm-devel] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
Date: Wed, 27 May 2015 01:40:22 +0100 [thread overview]
Message-ID: <20150527004022.GD31182@agk-dp.fab.redhat.com> (raw)
In-Reply-To: <20150527090640.44c346e2@notabene.brown>
On Wed, May 27, 2015 at 09:06:40AM +1000, Neil Brown wrote:
> Because we don't know what the "right" size is. And the "right" size can
> change when array reconfiguration happens.
In certain configurations today, device-mapper does report back a sensible
maximum bio size smaller than would otherwise be used and thereby avoids
retrospective splitting. (In tests, the overhead of the duplicate calculation
was found to be negligible so we never restructured the code to optimise it away.)
> Splitting has to happen somewhere, if only in bio_addpage where it decides to
> create a new bio rather than add another page to the current one. So moving
> the split to a different level of the stack shouldn't necessarily change the
> performance profile.
It does sometimes make a significant difference to device-mapper stacks.
DM only uses it for performance reasons - it can already split bios when
it needs to. I tried to remove merge_bvec_fn from DM several years ago but
couldn't because of the adverse performance impact of lots of splitting activity.
The overall cost of splitting ought to be less in many (but not necessarily
all) cases now as a result of all these patches, so exactly where the best
balance lies now needs to be reassessed empirically. It is hard to reach
conclusions theoretically because of the complex interplay between the various
factors at different levels.
Alasdair
next prev parent reply other threads:[~2015-05-27 8:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1432318723-18829-1-git-send-email-mlin@kernel.org>
2015-05-22 18:18 ` [Drbd-dev] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios Ming Lin
2015-05-25 5:46 ` NeilBrown
2015-05-26 14:36 ` Mike Snitzer
2015-05-26 15:02 ` Ming Lin
2015-05-26 15:34 ` Alasdair G Kergon
2015-05-26 23:06 ` NeilBrown
2015-05-27 0:40 ` Alasdair G Kergon [this message]
2015-05-27 8:20 ` [Drbd-dev] [dm-devel] " Christoph Hellwig
2015-05-26 16:04 ` [Drbd-dev] " Mike Snitzer
2015-05-26 17:17 ` Ming Lin
2015-05-27 23:42 ` Ming Lin
2015-05-28 0:36 ` Alasdair G Kergon
2015-05-28 5:54 ` Ming Lin
2015-05-29 7:05 ` Ming Lin
2015-05-29 15:15 ` Mike Snitzer
2015-06-01 6:02 ` Ming Lin
2015-06-02 20:59 ` Ming Lin
2015-06-04 21:06 ` Mike Snitzer
2015-06-04 22:21 ` Ming Lin
2015-06-05 0:06 ` Mike Snitzer
2015-06-05 5:21 ` Ming Lin
2015-06-09 6:09 ` Ming Lin
2015-06-10 21:20 ` Ming Lin
2015-06-10 21:46 ` Mike Snitzer
2015-06-10 22:06 ` Ming Lin
2015-06-12 5:49 ` Ming Lin
2015-06-18 5:27 ` Ming Lin
2015-05-22 18:18 ` [Drbd-dev] [PATCH v4 08/11] block: kill merge_bvec_fn() completely Ming Lin
2015-05-25 5:49 ` NeilBrown
2015-05-25 14:04 ` Christoph Hellwig
2015-05-25 15:02 ` Ilya Dryomov
2015-05-25 15:08 ` Christoph Hellwig
2015-05-25 15:19 ` Ilya Dryomov
2015-05-25 15:35 ` Alex Elder
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=20150527004022.GD31182@agk-dp.fab.redhat.com \
--to=agk@redhat.com \
--cc=Al@redhat.com \
--cc=Kent@redhat.com \
--cc=Oleg@redhat.com \
--cc=andreas.dilger@intel.com \
--cc=axboe@kernel.dk \
--cc=dchinner@redhat.com \
--cc=dm-devel@redhat.com \
--cc=dpark@posteo.net \
--cc=drbd-dev@lists.linbit.com \
--cc=drbd-user@lists.linbit.com \
--cc=geoff@infradead.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jim@jtan.com \
--cc=jkosina@suse.cz \
--cc=josh.h.morris@us.ibm.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=ming.lei@canonical.com \
--cc=mlin@kernel.org \
--cc=ngupta@vflare.org \
--cc=oleg.drokin@intel.com \
--cc=pjk1939@linux.vnet.ibm.com \
--cc=snitzer@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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