Re: Flush requests not going through IO scheduler

From: Jens Axboe
Date: Tue Nov 03 2015 - 12:24:20 EST

On 11/03/2015 10:18 AM, Jeff Moyer wrote:
Jens Axboe <axboe@xxxxxxxxx> writes:

Certainly, the current behavior is undoubtedly broken. The least
intrusive fix would be to kick off scheduling when we add it to the
request, but the elevator should handle it. Are you going to be up
for hacking up a fix?

I have some trouble understanding what do you mean exactly. Do you think we
should just call __blk_run_queue() after we add the request to

No, that won't be enough, as it won't always break out of the idle
logic. We need to ensure that the new request is noticed, so that CFQ
knows and can decide to kick off things.

Hmm? __blk_run_queue calls the request_fn, which will call
blk_peek_request, which calls __elv_next_request, which will find the
request on queue_head. Right?

while (1) {
if (!list_empty(&q->queue_head)) {
rq = list_entry_rq(q->;
return rq;

I guess that will bypass the schedule. Ugh, but that's pretty ugly, since cfq is still effectively idling. These flush requests really should go to an internal scheduler list for dispatch.

But as a quick fix, it might be enough to just kick off the queue with blk_run_queue().

Jens Axboe

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at