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 -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
