From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: Mike Snitzer <snitzer@redhat.com>
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 18:06:13 +0200 [thread overview]
Message-ID: <569675F5.8070501@dev.mellanox.co.il> (raw)
In-Reply-To: <20160113154243.GA2563@redhat.com>
> 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?
> 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
WARNING: multiple messages have this Message-ID (diff)
From: sagig@dev.mellanox.co.il (Sagi Grimberg)
Subject: [LSF/MM ATTEND][LSF/MM TOPIC] Multipath redesign
Date: Wed, 13 Jan 2016 18:06:13 +0200 [thread overview]
Message-ID: <569675F5.8070501@dev.mellanox.co.il> (raw)
In-Reply-To: <20160113154243.GA2563@redhat.com>
> 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?
> 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
next prev parent reply other threads:[~2016-01-13 16:06 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 [this message]
2016-01-13 16:06 ` Sagi Grimberg
2016-01-13 16:21 ` Mike Snitzer
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=569675F5.8070501@dev.mellanox.co.il \
--to=sagig@dev.mellanox.co.il \
--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=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.