renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-11-28 20:44:00 +08:00
Code

mq-deadline: make it clear that __dd_dispatch_request() works on all hw queues

Browse Source 
Don't pass in the hardware queue to __dd_dispatch_request(), since it
leads the reader to believe that we are returning a request for that
specific hardware queue. That's not how mq-deadline works, the state
for determining which request to serve next is shared across all
hardware queues for a device.

Reviewed-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This commit is contained in:
Jens Axboe 2018-01-06 09:23:11 -07:00
parent 14db491726
commit ca11f209a4
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
block/mq-deadline.c
View File

@ -267,9 +267,8 @@ deadline_next_request(struct deadline_data *dd, int data_dir)
* deadline_dispatch_requests selects the best request according to
* read/write expire, fifo_batch, etc
*/
static struct request *__dd_dispatch_request(struct blk_mq_hw_ctx *hctx)
static struct request *__dd_dispatch_request(struct deadline_data *dd)
{
struct deadline_data *dd = hctx->queue->elevator->elevator_data;
struct request *rq, *next_rq;
bool reads, writes;
int data_dir;
@ -372,13 +371,19 @@ done:
return rq;
}
/*
* One confusing aspect here is that we get called for a specific
* hardware queue, but we return a request that may not be for a
* different hardware queue. This is because mq-deadline has shared
* state for all hardware queues, in terms of sorting, FIFOs, etc.
*/
static struct request *dd_dispatch_request(struct blk_mq_hw_ctx *hctx)
{
struct deadline_data *dd = hctx->queue->elevator->elevator_data;
struct request *rq;
spin_lock(&dd->lock);
rq = __dd_dispatch_request(hctx);
rq = __dd_dispatch_request(dd);
spin_unlock(&dd->lock);
return rq;