Messages in this thread | | | Subject | Re: [PATCHSET/RFC v2] blk-mq scheduling framework | From | Jens Axboe <> | Date | Tue, 13 Dec 2016 14:51:27 -0700 |
| |
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
| |