Thread (72 messages) 72 messages, 4 authors, 2017-02-16

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

From: Paolo Valente <hidden>
Date: 2017-02-16 10:46:44
Also in: lkml

Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe [off-list ref] ha =
scritto:
=20
This is basically identical to deadline-iosched, except it registers
as a MQ capable scheduler. This is still a single queue design.
=20
Signed-off-by: Jens Axboe <axboe@fb.com>
...
+
+static void dd_merged_requests(struct request_queue *q, struct =
request *req,
+			       struct request *next)
+{
+	/*
+	 * if next expires before rq, assign its expire time to rq
+	 * and move into next position (next will be deleted) in fifo
+	 */
+	if (!list_empty(&req->queuelist) && =
!list_empty(&next->queuelist)) {
+		if (time_before((unsigned long)next->fifo_time,
+				(unsigned long)req->fifo_time)) {
+			list_move(&req->queuelist, &next->queuelist);
+			req->fifo_time =3D next->fifo_time;
+		}
+	}
+
Jens,
while trying to imagine the possible causes of Bart's hang with
bfq-mq, I've bumped into the following doubt: in the above function
(in my case, in bfq-mq-'s equivalent of the above function), are
we sure that neither req or next could EVER be in dd->dispatch instead
of dd->fifo_list?  I've tried to verify it, but, although I think it has =
never
happened in my tests, I was not able to make sure that no unlucky
combination may ever happen (considering also the use of
blk_rq_is_passthrough too, to decide where to put a new request).

I'm making a blunder, right?

Thanks,
Paolo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help