On 11/03/17 00:05, Jens Axboe wrote: > On 03/10/2017 07:21 AM, Adrian Hunter wrote: >>> Essentially I take out that thread and replace it with this one worker >>> introduced in this very patch. I agree the driver can block in many ways >>> and that is why I need to have it running in process context, and this >>> is what the worker introduced here provides. >> >> The last time I looked at the blk-mq I/O scheduler code, it pulled up to >> qdepth requests from the I/O scheduler and left them on a local list while >> running ->queue_rq(). That means blocking in ->queue_rq() leaves some >> number of requests in limbo (not issued but also not in the I/O scheduler) >> for that time. > > Look again, if we're not handling the requeued dispatches, we pull one > at the time from the scheduler. > That's good :-) Now the next thing ;-) It looks like we either set BLK_MQ_F_BLOCKING and miss the possibility of issuing synchronous requests immediately, or we don't set BLK_MQ_F_BLOCKING in which case we are never allowed to sleep in ->queue_rq(). Is that true?
