Re: [PATCHSET/RFC v2] blk-mq scheduling framework

[Jens Axboe <axboe@fb.com>]

On 12/13/2016 09:28 AM, Jens Axboe wrote:
>>> No worries, ask away if you have questions. As you might have seen, it's
>>> still a little bit of a moving target, but it's getting closer every
>>> day. I'll post a v3 later today hopefully that will be a good fix point
>>> for you. I'll need to add the io context setup etc, that's not there
>>> yet, as only cfq/bfq uses that.
>>>
>>
>> You anticipated the question that was worrying me more, how to handle
>> iocontexts :) I'll go on studying your patches while waiting for this
>> (last, right?) missing piece for bfq.
> 
> It's the last missing larger piece. We probably have a few hooks that
> BFQ/CFQ currently uses that aren't wired up yet in the elevator_ops for
> mq, so you'll probably have to do those as you go. I can take a look,
> but I would prefer if they be done one a as-needed basis. Perhaps we can
> get rid of some of them.

The current 'blk-mq-sched' branch has support for getting the IO
contexts setup, and assigned to requests. Only works off the task
io_context for now, we ignore anything set in the bio. But that's a
minor thing, generally it should work for you.

Note that the mq ops have different naming than the classic elevator
ops. For instance, the set_request/put_request are
get_rq_priv/put_rq_priv instead. Others are different as well. In
general, refer to mq-deadline.c for how the hooks work and you can
compare with deadline-iosched.c, since they are still very close.

Note that the io context linking uses the embedded queue lock,
q->queue_lock, whereas for other things you are free to use a lock
embedded in the your elevator data. Again, refer to mq-deadline, it uses
dd->lock to protect the hash/rbtree. If mq-deadline used io contexts, it
would manage those behind q->queue_lock.

-- 
Jens Axboe