Hello, Jens.
Hello, Andrew.
In cfq_find_next_crq(), cfq tries to find the next request by
choosing one of two requests before and after the current one.
Currently, when choosing the next request, if there's no next request,
the next candidate is NULL, resulting in selection of the previous
request. This results in weird scheduling. Once we reach the end, we
always seek backward.
The correct behavior is using the first request as the next
candidate. cfq_choose_req() already has logics for handling wrapped
requests.
Signed-off-by: Tejun Heo <[email protected]>
Index: blk-fixes/drivers/block/cfq-iosched.c
===================================================================
--- blk-fixes.orig/drivers/block/cfq-iosched.c 2005-06-15 22:44:55.000000000 +0900
+++ blk-fixes/drivers/block/cfq-iosched.c 2005-06-15 22:45:21.000000000 +0900
@@ -375,9 +375,10 @@ cfq_find_next_crq(struct cfq_data *cfqd,
struct cfq_rq *crq_next = NULL, *crq_prev = NULL;
struct rb_node *rbnext, *rbprev;
+ rbnext = NULL;
if (ON_RB(&last->rb_node))
rbnext = rb_next(&last->rb_node);
- else {
+ if (!rbnext) {
rbnext = rb_first(&cfqq->sort_list);
if (rbnext == &last->rb_node)
rbnext = NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
