linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Ming Lei <ming.lei@redhat.com>, axboe@kernel.dk
Cc: Jens Axboe <axboe@fb.com>,
	linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	dm-devel@redhat.com, Bart Van Assche <bart.vanassche@sandisk.com>
Subject: Re: [PATCH V3 0/5]  dm-rq: improve sequential I/O performance
Date: Thu, 11 Jan 2018 17:07:42 -0500	[thread overview]
Message-ID: <20180111220742.GA31944@redhat.com> (raw)
In-Reply-To: <20180111060159.12991-1-ming.lei@redhat.com>

On Thu, Jan 11 2018 at  1:01am -0500,
Ming Lei <ming.lei@redhat.com> wrote:

> 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.

In general the delayed requeue was meant to cope (slightly better) with
queue_if_no_path and no paths being available.  I think patch 1 respect
that intent.  And patch 2 looks right to me, BLK_STS_RESOURCE definitely
should be returned if blk_get_request() fails.

So I picked these up for dm-4.16 (and staged them in linux-next).  I
reworded both headers and the 2nd patch's block comment, see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.16&id=64e4e12bf474cf3aaaf59245bbeba3057d2fedf9
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.16&id=c50de17c1cc7d5910df58aba9b950e99579e239d

Bart, if for some reason we regress for some workload you're able to
more readily test we can deal with it.  But I'm too encouraged by Ming's
performance improvements to hold these changes back any further.

> 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 whole patchset improves
> sequential IO by 3X ~ 5X.

I've merged dm-4.16 and for-4.16/block and patched 3 - 5 apply cleanly
(so we won't have any merge conflicts during 4.16), resulting git branch
is here:
https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/log/?h=block-4.16_dm-4.16

I'll reply to patches 3 - 5 individually with my Reviewed-by.
Jens, please feel free to pick them up for 4.16.

Thanks,
Mike

  parent reply	other threads:[~2018-01-11 22:07 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11  6:01 [PATCH V3 0/5] dm-rq: improve sequential I/O performance Ming Lei
2018-01-11  6:01 ` [PATCH V3 1/5] dm-mpath: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE Ming Lei
2018-01-11  6:01 ` [PATCH V3 2/5] dm-mpath: return DM_MAPIO_REQUEUE in case of rq allocation failure Ming Lei
2018-01-12 19:04   ` Bart Van Assche
2018-01-13  1:29     ` Ming Lei
2018-01-11  6:01 ` [PATCH V3 3/5] blk-mq: move actual issue into one helper Ming Lei
2018-01-11 22:09   ` Mike Snitzer
2018-01-11  6:01 ` [PATCH V3 4/5] blk-mq: return dispatch result to caller in blk_mq_try_issue_directly Ming Lei
2018-01-11 22:10   ` Mike Snitzer
2018-01-11  6:01 ` [PATCH V3 5/5] blk-mq: issue request directly for blk_insert_cloned_request Ming Lei
2018-01-11 22:42   ` Mike Snitzer
2018-01-11 22:07 ` Mike Snitzer [this message]
2018-01-11 22:37   ` [PATCH V3 0/5] dm-rq: improve sequential I/O performance Bart Van Assche
2018-01-11 22:58     ` Mike Snitzer
2018-01-11 23:27       ` Bart Van Assche
2018-01-12  1:43         ` Mike Snitzer
2018-01-12  1:42     ` Ming Lei
2018-01-12  1:57       ` Mike Snitzer
2018-01-12  3:33         ` Ming Lei
2018-01-12 17:18           ` Mike Snitzer
2018-01-12 17:26             ` Bart Van Assche
2018-01-12 17:40               ` Mike Snitzer
2018-01-12 17:46                 ` Bart Van Assche
2018-01-12 18:06                   ` Mike Snitzer
2018-01-12 18:54                     ` Bart Van Assche
2018-01-12 19:29                       ` Mike Snitzer
2018-01-12 19:53                       ` Elliott, Robert (Persistent Memory)
2018-01-13  0:52                         ` Mike Snitzer
2018-01-13  1:00                           ` Bart Van Assche
2018-01-13  1:37                             ` Mike Snitzer
2018-01-13 15:14                               ` Mike Snitzer
2018-01-12 22:31                       ` Mike Snitzer
2018-01-13 15:04                         ` Ming Lei
2018-01-13 15:10                           ` Mike Snitzer
2018-01-12 23:17                       ` Mike Snitzer
2018-01-12 23:42                         ` Bart Van Assche
2018-01-13  0:45                           ` Mike Snitzer
2018-01-13 14:34                       ` 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=20180111220742.GA31944@redhat.com \
    --to=snitzer@redhat.com \
    --cc=axboe@fb.com \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@sandisk.com \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@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;
as well as URLs for NNTP newsgroup(s).