Re: Flush requests not going through IO scheduler

[Jens Axboe <axboe@kernel.dk>]

On 11/03/2015 10:18 AM, Jeff Moyer wrote:
> Jens Axboe <axboe@kernel.dk> 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
>>> q->queue_head?
>>
>> 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->queue_head.next);
>                          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