From: Mike Snitzer <snitzer@redhat.com>
To: Sagi Grimberg <sagig@dev.mellanox.co.il>
Cc: Hannes Reinecke <hare@suse.de>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
device-mapper development <dm-devel@redhat.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-scsi@vger.kernel.org" <Linux-scsi@vger.kernel.org>
Subject: Re: [LSF/MM ATTEND][LSF/MM TOPIC] Multipath redesign
Date: Wed, 13 Jan 2016 11:21:03 -0500 [thread overview]
Message-ID: <20160113162102.GA2933@redhat.com> (raw)
In-Reply-To: <569675F5.8070501@dev.mellanox.co.il>
On Wed, Jan 13 2016 at 11:06am -0500,
Sagi Grimberg <sagig@dev.mellanox.co.il> wrote:
>
> >This sounds like you aren't actually using blk-mq for the top-level DM
> >multipath queue.
>
> Hmm. I turned on /sys/module/dm_mod/parameters/use_blk_mq and indeed
> saw a significant performance improvement. Anything else I was missing?
You can enable CONFIG_DM_MQ_DEFAULT so you don't need to manually set
use_blk_mq.
> >And your findings contradicts what I heard from Keith
> >Busch when I developed request-based DM's blk-mq support, from commit
> >bfebd1cdb497 ("dm: add full blk-mq support to request-based DM"):
> >
> > "Just providing a performance update. All my fio tests are getting
> > roughly equal performance whether accessed through the raw block
> > device or the multipath device mapper (~470k IOPS). I could only push
> > ~20% of the raw iops through dm before this conversion, so this latest
> > tree is looking really solid from a performance standpoint."
>
> I too see ~500K IOPs, but my nvme can push ~1500K IOPs...
> Its a simple nvme loopback [1] backed by null_blk.
>
> [1]:
> http://lists.infradead.org/pipermail/linux-nvme/2015-November/003001.html
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/nvme-loop.2
OK, so you're only getting 1/3 of the throughput. Time for us to hunt
down the bottleneck (before real devices hit it).
WARNING: multiple messages have this Message-ID (diff)
From: snitzer@redhat.com (Mike Snitzer)
Subject: [LSF/MM ATTEND][LSF/MM TOPIC] Multipath redesign
Date: Wed, 13 Jan 2016 11:21:03 -0500 [thread overview]
Message-ID: <20160113162102.GA2933@redhat.com> (raw)
In-Reply-To: <569675F5.8070501@dev.mellanox.co.il>
On Wed, Jan 13 2016 at 11:06am -0500,
Sagi Grimberg <sagig@dev.mellanox.co.il> wrote:
>
> >This sounds like you aren't actually using blk-mq for the top-level DM
> >multipath queue.
>
> Hmm. I turned on /sys/module/dm_mod/parameters/use_blk_mq and indeed
> saw a significant performance improvement. Anything else I was missing?
You can enable CONFIG_DM_MQ_DEFAULT so you don't need to manually set
use_blk_mq.
> >And your findings contradicts what I heard from Keith
> >Busch when I developed request-based DM's blk-mq support, from commit
> >bfebd1cdb497 ("dm: add full blk-mq support to request-based DM"):
> >
> > "Just providing a performance update. All my fio tests are getting
> > roughly equal performance whether accessed through the raw block
> > device or the multipath device mapper (~470k IOPS). I could only push
> > ~20% of the raw iops through dm before this conversion, so this latest
> > tree is looking really solid from a performance standpoint."
>
> I too see ~500K IOPs, but my nvme can push ~1500K IOPs...
> Its a simple nvme loopback [1] backed by null_blk.
>
> [1]:
> http://lists.infradead.org/pipermail/linux-nvme/2015-November/003001.html
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/nvme-loop.2
OK, so you're only getting 1/3 of the throughput. Time for us to hunt
down the bottleneck (before real devices hit it).
next prev parent reply other threads:[~2016-01-13 16:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 9:10 [LSF/MM ATTEND][LSF/MM TOPIC] Multipath redesign Hannes Reinecke
2016-01-13 10:50 ` Sagi Grimberg
2016-01-13 10:50 ` Sagi Grimberg
2016-01-13 11:46 ` Hannes Reinecke
2016-01-13 11:46 ` Hannes Reinecke
2016-01-13 15:42 ` Mike Snitzer
2016-01-13 15:42 ` Mike Snitzer
2016-01-13 16:06 ` Sagi Grimberg
2016-01-13 16:06 ` Sagi Grimberg
2016-01-13 16:21 ` Mike Snitzer [this message]
2016-01-13 16:21 ` Mike Snitzer
2016-01-13 16:30 ` Sagi Grimberg
2016-01-13 16:30 ` Sagi Grimberg
2016-01-13 16:18 ` Hannes Reinecke
2016-01-13 16:18 ` Hannes Reinecke
2016-01-13 16:54 ` Mike Snitzer
2016-01-13 16:54 ` Mike Snitzer
2016-01-13 11:08 ` [dm-devel] " Alasdair G Kergon
2016-01-13 11:17 ` Hannes Reinecke
2016-01-13 11:25 ` Alasdair G Kergon
2016-01-13 17:52 ` Benjamin Marzinski
2016-01-14 7:25 ` Hannes Reinecke
2016-01-14 19:09 ` Bart Van Assche
2016-01-15 7:12 ` Hannes Reinecke
2016-01-21 0:38 ` Benjamin Marzinski
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=20160113162102.GA2933@redhat.com \
--to=snitzer@redhat.com \
--cc=Linux-scsi@vger.kernel.org \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=linux-nvme@lists.infradead.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=sagig@dev.mellanox.co.il \
/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.