From ccdf10076e55d791ce914162a4454bdd56fc08f3 Mon Sep 17 00:00:00 2001 From: Arianna Avanzini Date: Thu, 23 Jan 2014 14:21:55 +0100 Subject: [PATCH 2/2] block: Switch from BFQ-v6r2 for 3.6.0 to BFQ-v7 for 3.6.0 - second part Improvements: - An application must be non-greedy to be deemed as soft real-time (it is one of the conditions to meet). The condition is checked by controlling whether a long-enough time interval, by default HZ/125 seconds, elapsed from when the queue associated to the application became idle, to when the queue becomes backlogged again. Elapsed time is measured in jiffies. This control easily generates false positives in the following two cases (especially if both cases occur): 1) If HZ is so low that the duration of a jiffie is comparable to or higher than the above reference time interval. This happens, e.g., on slow devices with HZ=100. 2) If jiffies, instead of increasing at a constant rate, may stop increasing for some time, then suddenly 'jump' by several units to recover the lost increments. This seems to happen, e.g., in virtual machines. This commit adds a few jiffies to the above reference time interval. We found the number of jiffies to add experimentally. In particular, according to our experiments, the number of jiffies added by this commit seems to make the filter quite precise also in embedded systems and KVM/QEMU virtual machines. Signed-off-by: Paolo Valente Signed-off-by: Alexander Spyridakis Signed-off-by: Arianna Avanzini --- block/bfq-iosched.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 54761a3..61487ee 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1672,6 +1672,20 @@ static int bfq_update_peak_rate(struct bfq_data *bfqd, struct bfq_queue *bfqq, * request as soon as possible after the last one has been completed (in * contrast, when a batch of requests is completed, a soft real-time * application spends some time processing data). + * + * Actually, the last filter may easily generate false positives if: only + * bfqd->bfq_slice_idle is used as a reference time interval, and one or + * both the following two cases occur: + * 1) HZ is so low that the duration of a jiffie is comparable to or higher + * than bfqd->bfq_slice_idle. This happens, e.g., on slow devices with + * HZ=100. + * 2) jiffies, instead of increasing at a constant rate, may stop increasing + * for a while, then suddenly 'jump' by several units to recover the lost + * increments. This seems to happen, e.g., inside virtual machines. + * To address this issue, we do not use as a reference time interval just + * bfqd->bfq_slice_idle, but bfqd->bfq_slice_idle plus a few jiffies. In + * particular we add the minimum number of jiffies for which the filter seems + * to be quite precise also in embedded systems and KVM/QEMU virtual machines. */ static inline u64 bfq_bfqq_softrt_next_start(struct bfq_data *bfqd, struct bfq_queue *bfqq) @@ -1679,7 +1693,7 @@ static inline u64 bfq_bfqq_softrt_next_start(struct bfq_data *bfqd, return max(bfqq->last_idle_bklogged + HZ * bfqq->service_from_backlogged / bfqd->bfq_raising_max_softrt_rate, - (u64)jiffies + bfqd->bfq_slice_idle); + (u64)jiffies + bfqq->bfqd->bfq_slice_idle + 4); } /** -- 1.8.5.2