[PATCH 24/23] io-controller: Don't leave a queue active when adisk is idle

[Vivek Goyal]

o It is possible that when there is only a single queue in the system, it
  remains unexpired for a long time (because there is no IO activity on the
  disk). So when next request comes in after a long time, it might make
  scheduler think that all this while queue used the disk and it will assign
  a high vdisktime to the queue. Hence make sure queue is expired once all
  the requests have completed from the queue.

o Also avoid unnecessarily expiring a queue when it has got one request
  dispatched to the queue and waiting for it to finish and it does not have
  more requests queued to dispatch.

Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
---
 block/elevator-fq.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

Index: linux16/block/elevator-fq.c
===================================================================
--- linux16.orig/block/elevator-fq.c	2009-09-08 15:43:36.000000000 -0400
+++ linux16/block/elevator-fq.c	2009-09-08 15:44:21.000000000 -0400
@@ -2947,6 +2947,10 @@ void *elv_select_ioq(struct request_queu
 	if (ioq == NULL)
 		goto new_queue;
 
+	/* There is only one active queue which is empty. Nothing to dispatch */
+	if (elv_nr_busy_ioq(q->elevator) == 1 && !ioq->nr_queued)
+		return NULL;
+
 	iog = ioq_to_io_group(ioq);
 
 	/*
@@ -3236,6 +3240,17 @@ void elv_ioq_completed_request(struct re
 			else
 				elv_iog_arm_slice_timer(q, iog, 0);
 		}
+
+		/*
+		 * if this is only queue and it has completed all its requests
+		 * and has nothing to dispatch, expire it. We don't want to
+		 * keep it around idle otherwise later when it is expired, all
+		 * this idle time will be added to queue's disk time used.
+		 */
+		if (efqd->busy_queues == 1 && !ioq->dispatched &&
+		   !ioq->nr_queued && !timer_pending(&efqd->idle_slice_timer)) {
+			elv_slice_expired(q);
+		}
 	}
 done:
 	if (!efqd->rq_in_driver)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/