From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@fb.com>,
linux-block@vger.kernel.org, Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com
Cc: Christoph Hellwig <hch@infradead.org>,
Bart Van Assche <bart.vanassche@sandisk.com>,
linux-kernel@vger.kernel.org, Hannes Reinecke <hare@suse.com>,
Omar Sandoval <osandov@fb.com>, Ming Lei <ming.lei@redhat.com>
Subject: [PATCH V2 0/5] dm-rq: improve sequential I/O performance
Date: Mon, 27 Nov 2017 13:07:16 +0800 [thread overview]
Message-ID: <20171127050721.5884-1-ming.lei@redhat.com> (raw)
Hi Guys,
The 1st patch removes the workaround of blk_mq_delay_run_hw_queue() in
case of requeue, this way isn't necessary, and more worse, it makes
BLK_MQ_S_SCHED_RESTART not working, and degarde I/O performance.
The 2nd patch return DM_MAPIO_REQUEUE to dm-rq if underlying request
allocation fails, then we can return BLK_STS_RESOURCE from dm-rq to
blk-mq, so that blk-mq can hold the requests to be dequeued.
The other 3 paches changes the blk-mq part of blk_insert_cloned_request(),
in which we switch to blk_mq_try_issue_directly(), so that both dm-rq
and blk-mq can get the dispatch result of underlying queue, and with
this information, blk-mq can handle IO merge much better, then
sequential I/O performance is improved much. In my dm-mpath over
virtio-scsi test, this improvement can be 3X ~ 5X.
V2:
- drop 'dm-mpath: cache ti->clone during requeue', which is a bit
too complicated, and not see obvious performance improvement.
- make change on blk-mq part cleaner
Ming Lei (5):
dm-mpath: don't call blk_mq_delay_run_hw_queue() in case of
BLK_STS_RESOURCE
dm-mpath: return DM_MAPIO_REQUEUE in case of rq allocation failure
blk-mq: move actual issue into one helper
blk-mq: return dispatch result to caller in blk_mq_try_issue_directly
blk-mq: issue request directly for blk_insert_cloned_request
block/blk-core.c | 3 +-
block/blk-mq.c | 88 +++++++++++++++++++++++++++++++++++++++------------
block/blk-mq.h | 3 ++
drivers/md/dm-mpath.c | 18 ++++++++---
drivers/md/dm-rq.c | 20 +++++++++---
5 files changed, 102 insertions(+), 30 deletions(-)
--
2.9.5
next reply other threads:[~2017-11-27 5:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 5:07 Ming Lei [this message]
2017-11-27 5:07 ` [PATCH V2 1/5] dm-mpath: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE Ming Lei
2017-11-27 17:14 ` Bart Van Assche
2017-12-01 2:01 ` Ming Lei
2017-11-27 5:07 ` [PATCH V2 2/5] dm-mpath: return DM_MAPIO_REQUEUE in case of rq allocation failure Ming Lei
2017-11-27 5:07 ` [PATCH V2 3/5] blk-mq: move actual issue into one helper Ming Lei
2017-11-27 5:07 ` [PATCH V2 4/5] blk-mq: return dispatch result to caller in blk_mq_try_issue_directly Ming Lei
2017-11-27 5:07 ` [PATCH V2 5/5] blk-mq: issue request directly for blk_insert_cloned_request Ming Lei
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=20171127050721.5884-1-ming.lei@redhat.com \
--to=ming.lei@redhat.com \
--cc=axboe@fb.com \
--cc=bart.vanassche@sandisk.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=osandov@fb.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox