mq-deadline: make it clear that __dd_dispatch_request() works on all hw queues
authorJens Axboe <axboe@kernel.dk>
Sat, 6 Jan 2018 16:23:11 +0000 (09:23 -0700)
committerJens Axboe <axboe@kernel.dk>
Sat, 6 Jan 2018 16:23:11 +0000 (09:23 -0700)
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>
block/mq-deadline.c

index d56972e8ebda579cb141d326f9dc774d386f2ffb..c56f211c84400662f3e18c137b51c3f5406e20fd 100644 (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;