Re: [PATCH 5/5] blk-mq-sched: change ->dispatch_requests() to ->dispatch_request()

[Omar Sandoval <osandov@osandov.com>]

On Thu, Jan 26, 2017 at 12:48:18PM -0700, Jens Axboe wrote:
> When we invoke dispatch_requests(), the scheduler empties everything
> into the passed in list. This isn't always a good thing, since it
> means that we remove items that we could have potentially merged
> with.
> 
> Change the function to dispatch single requests at the time. If
> we do that, we can backoff exactly at the point where the device
> can't consume more IO, and leave the rest with the scheduler for
> better merging and future dispatch decision making.

Hmm, I think I previously changed this from ->dispatch_request() to
->dispatch_requests() to support schedulers using software queues. My
current mq-token stuff doesn't have a ->dispatch_requests() hook anymore
after the sched_tags rework, but I think I'm going to need it again
soon. Having the scheduler do blk_mq_flush_busy_ctxs() into its own
private list and then handing the requests out one-by-one kinda sucks.
(Plus, deferred issue wouldn't work with this, but it's not implemented,
anyways :)

One idea: what if we have the scheduler get the driver tags inside of
its ->dispatch_requests()? For example, __dd_dispatch_request() could
first check whether it has a request to dispatch and then try to grab a
driver tag. If it succeeds, it dispatches the request, and if it
doesn't, it marks itself as needing restart.

With that, the scheduler will only return requests ready for
->queue_rq(), meaning we could get rid of the list reshuffling in
blk_mq_dispatch_rq_list().

> Signed-off-by: Jens Axboe <axboe@fb.com>
> ---
>  block/blk-mq-sched.c     | 23 +++++++++++++++--------
>  block/blk-mq.c           |  2 +-
>  block/mq-deadline.c      | 10 ++++++----
>  include/linux/elevator.h |  2 +-
>  4 files changed, 23 insertions(+), 14 deletions(-)