From: Alasdair G Kergon <agk@redhat.com>
To: Ming Lin <mlin@kernel.org>
Cc: Mike Snitzer <snitzer@redhat.com>,
lkml <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
Kent Overstreet <kent.overstreet@gmail.com>,
Jens Axboe <axboe@kernel.dk>, Dongsu Park <dpark@posteo.net>,
Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Ming Lei <ming.lei@canonical.com>, Neil Brown <neilb@suse.de>,
Alasdair Kergon <agk@redhat.com>,
dm-devel@redhat.com, Lars Ellenberg <drbd-dev@lists.linbit.com>,
drbd-user@lists.linbit.com, Jiri Kosina <jkosina@suse.cz>,
Geoff Levand <geoff@infradead.org>, Jim Paris <jim@jtan.com>,
Joshua Morris <josh.h.morris@us.ibm.com>,
Philip Kelleher <pjk1939@linux.vnet.ibm.com>,
Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
Oleg Drokin <oleg.drokin@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>
Subject: Re: [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
Date: Thu, 28 May 2015 01:36:27 +0100 [thread overview]
Message-ID: <20150528003627.GD32216@agk-dp.fab.redhat.com> (raw)
In-Reply-To: <CAF1ivSZ351yV4re1Ghf5yqPjgq6aXjrZT4yWd+T9msAFsBnDSw@mail.gmail.com>
On Wed, May 27, 2015 at 04:42:44PM -0700, Ming Lin wrote:
> Here are fio results of XFS on a DM stripped target with 2 SSDs + 1 HDD.
> Does it make sense?
To stripe across devices with different characteristics?
Some suggestions.
Prepare 3 kernels.
O - Old kernel.
M - Old kernel with merge_bvec_fn disabled.
N - New kernel.
You're trying to search for counter-examples to the hypothesis that
"Kernel N always outperforms Kernel O". Then if you find any, trying
to show either that the performance impediment is small enough that
it doesn't matter or that the cases are sufficiently rare or obscure
that they may be ignored because of the greater benefits of N in much more
common cases.
(1) You're looking to set up configurations where kernel O performs noticeably
better than M. Then you're comparing the performance of O and N in those
situations.
(2) You're looking at other sensible configurations where O and M have
similar performance, and comparing that with the performance of N.
In each case you find, you expect to be able to vary some parameter (such as
stripe size) to show a progression of the effect.
When running tests you've to take care the system is reset into the same
initial state before each test, so you'll normally also try to include some
baseline test between tests that should give the same results each time
and also take the average of a number of runs (while also reporting some
measure of the variation within each set to make sure that remains low,
typically a low single digit percentage).
Since we're mostly concerned about splitting, you'll want to monitor
iostat to see if that gives you enough information to home in on
suitable configurations for (1). Failing that, you might need to
instrument the kernels to tell you the sizes of the bios being
created and the amount of splitting actually happening.
Striping was mentioned because it forces splitting. So show the progression
from tiny stripes to huge stripes. (Ensure all the devices providing the
stripes have identical characteristics, but you can test with slow and
fast underlying devices.)
You may also want to test systems with a restricted amount of available
memory to show how the splitting via worker thread performs. (Again,
instrument to prove the extent to which the new code is being exercised.)
Alasdair
next prev parent reply other threads:[~2015-05-28 0:36 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 18:18 [PATCH v4 00/11] simplify block layer based on immutable biovecs Ming Lin
2015-05-22 18:18 ` [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 ` [dm-devel] " Alasdair G Kergon
2015-05-27 8:20 ` Christoph Hellwig
2015-05-26 16:04 ` Mike Snitzer
2015-05-26 17:17 ` Ming Lin
2015-05-27 23:42 ` Ming Lin
2015-05-28 0:36 ` Alasdair G Kergon [this message]
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 ` [PATCH v4 02/11] block: simplify bio_add_page() Ming Lin
2015-05-22 18:18 ` [PATCH v4 03/11] bcache: remove driver private bio splitting code Ming Lin
2015-05-22 18:18 ` [PATCH v4 04/11] btrfs: remove bio splitting and merge_bvec_fn() calls Ming Lin
2015-05-22 18:18 ` [PATCH v4 05/11] block: remove split code in blkdev_issue_discard Ming Lin
2015-05-22 18:18 ` [PATCH v4 06/11] md/raid5: get rid of bio_fits_rdev() Ming Lin
2015-05-25 5:48 ` NeilBrown
2015-05-25 7:03 ` Ming Lin
2015-05-25 7:54 ` NeilBrown
2015-05-25 14:17 ` Christoph Hellwig
2015-05-26 14:33 ` Ming Lin
2015-05-26 22:32 ` Ming Lin
2015-05-26 23:03 ` NeilBrown
2015-05-26 23:42 ` Ming Lin
2015-05-27 0:38 ` NeilBrown
2015-05-27 8:15 ` Christoph Hellwig
2015-05-22 18:18 ` [PATCH v4 07/11] md/raid5: split bio for chunk_aligned_read Ming Lin
2015-05-22 18:18 ` [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
2015-05-22 18:18 ` [PATCH v4 09/11] fs: use helper bio_add_page() instead of open coding on bi_io_vec Ming Lin
2015-05-22 18:18 ` [PATCH v4 10/11] block: remove bio_get_nr_vecs() Ming Lin
2015-05-22 18:18 ` [PATCH v4 11/11] Documentation: update notes in biovecs about arbitrarily sized bios Ming Lin
2015-05-23 14:15 ` [PATCH v4 00/11] simplify block layer based on immutable biovecs Christoph Hellwig
2015-05-24 7:37 ` Ming Lin
2015-05-25 13:51 ` Christoph Hellwig
2015-05-29 6:39 ` Ming Lin
2015-06-01 6:15 ` Ming Lin
2015-06-03 6:57 ` Christoph Hellwig
2015-06-03 13:28 ` Jeff Moyer
2015-06-03 17:06 ` Ming Lin
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=20150528003627.GD32216@agk-dp.fab.redhat.com \
--to=agk@redhat.com \
--cc=andreas.dilger@intel.com \
--cc=axboe@kernel.dk \
--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=neilb@suse.de \
--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;
as well as URLs for NNTP newsgroup(s).