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@xxxxxx> > --- > 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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
