[RFC,PATCH] cfq-iosched: improve async queue ramp up formula
From: Corrado Zoccolo
Date: Thu Nov 26 2009 - 11:10:59 EST
The introduction of ramp-up formula for async queue depths has
slowed down dirty page reclaim, by reducing async write performance.
This patch improves the formula by considering the remaining slice.
The new formula will allow more dispatches at the beginning of the
slice, reducing them at the end.
This will ensure that we achieve good throughput, without the risk of
overrunning the allotted timeslice.
The threshold is automatically increased when sync I/O is not
intermingled with async, in accordance with the previous incarnation of
the formula.
Signed-off-by: Corrado Zoccolo <czoccolo@xxxxxxxxx>
---
block/cfq-iosched.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index a5de31f..799782d 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1633,12 +1633,24 @@ static bool cfq_may_dispatch(struct cfq_data *cfqd, struct cfq_queue *cfqq)
* based on the last sync IO we serviced
*/
if (!cfq_cfqq_sync(cfqq) && cfqd->cfq_latency) {
- unsigned long last_sync = jiffies - cfqd->last_end_sync_rq;
- unsigned int depth;
-
- depth = last_sync / cfqd->cfq_slice[1];
- if (!depth && !cfqq->dispatched)
- depth = 1;
+ unsigned long now = jiffies;
+ unsigned long last_sync = now - cfqd->last_end_sync_rq;
+ unsigned int depth = 1;
+ if (cfqq->slice_end > now) {
+ unsigned int num,den;
+ /*
+ * (cfqq->slice_end - now) / cfqd->cfq_slice_idle
+ * approximates the number of requests that can be
+ * dispatched before our slice ends
+ * last_sync/cfq_slice[1] gives a boost when no
+ * concurrent sync activity is expected
+ */
+ num = last_sync * (cfqq->slice_end - now);
+ den = cfqd->cfq_slice[1] * cfqd->cfq_slice_idle;
+ if (!den)
+ den++;
+ depth += num / den;
+ }
if (depth < max_dispatch)
max_dispatch = depth;
}
--
1.6.2.5
--
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/