On Thu, Oct 27, 2016 at 12:21:06PM -0600, Jens Axboe wrote:

On 10/27/2016 12:13 PM, Ulf Hansson wrote:

quoted

I can imagine, that it's not always a straight forward "convert to blk
mq" patch for every block device driver.

Well, I've actually done a few conversions, and it's not difficult at
all. The grunt of the work is usually around converting to using some of
the blk-mq features for parts of the driver that it had implemented
privately, like timeout handling, etc.

Plus the benchmarking to verify that it works well of course, especially
initially where it'll also be a new queue infrastructure as well as the
blk-mq conversion itself.  It does feel like something that's going to
take at least a couple of kernel releases to get through.

quoted

quoted

quoted

3)
While we work on scheduling in blkmq (at least for single queue
devices), it's of course important that we set high goals. Having BFQ
(and the other schedulers) in the legacy blk, provides a good
reference for what we could aim for.

quoted

quoted

Sure, but you don't need BFQ to be included in the kernel for that.

quoted

Perhaps not.

quoted

But does that mean, you expect Paolo to maintain an up to date BFQ
tree for you?

I don't expect anything. If Paolo or others want to compare with BFQ on
the legacy IO path, then they can do that however way they want. If you
(and others) want to have that reference point, it's up to you how to
accomplish that.

I think there's also value in having improvements there for people who
benefit from them while queue infrastructure for blk-mq is being worked
on.