[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x498u6f2e97.fsf@segfault.boston.devel.redhat.com>
Date: Tue, 03 Nov 2015 12:18:12 -0500
From: Jeff Moyer <jmoyer@...hat.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Flush requests not going through IO scheduler
Jens Axboe <axboe@...nel.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;
Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists