> Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe <axboe@xxxxxxxxx> ha scritto: > > On 10/26/2016 09:29 AM, Christoph Hellwig wrote: >> On Wed, Oct 26, 2016 at 05:13:07PM +0200, Arnd Bergmann wrote: >>> The question to ask first is whether to actually have pluggable >>> schedulers on blk-mq at all, or just have one that is meant to >>> do the right thing in every case (and possibly can be bypassed >>> completely). >> >> That would be my preference. Have a BFQ-variant for blk-mq as an >> option (default to off unless opted in by the driver or user), and >> not other scheduler for blk-mq. Don't bother with bfq for non >> blk-mq. It's not like there is any advantage in the legacy-request >> device even for slow devices, except for the option of having I/O >> scheduling. > > It's the only right way forward. blk-mq might not offer any substantial > advantages to rotating storage, but with scheduling, it won't offer a > downside either. And it'll take us towards the real goal, which is to > have just one IO path. ok > Adding a new scheduler for the legacy IO path > makes no sense. I would fully agree if effective and stable I/O scheduling would be available in blk-mq in one or two months. But I guess that it will take at least one year optimistically, given the current status of the needed infrastructure, and given the great difficulties of doing effective scheduling at the high parallelism and extreme target speeds of blk-mq. Of course, this holds true unless little clever scheduling is performed. So, what's the point in forcing a lot of users wait another year or more, for a solution that has yet to be even defined, while they could enjoy a much better system, and then switch an even better system when scheduling is ready in blk-mq too? For example, currently, opening a terminal on a 50KIOPS SSD with cfq, deadline or noop, if there happens to be some background workload, takes *more* time than opening the same terminal on a 1KIOPS HDD with the same background workload, but with BFQ. Does this make any sense? > Adding one for blk-mq and phasing out the old path is > what we need to do. > Yes, as the ultimate goal. Thanks, Paolo > -- > 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
