[...] > > I'm hesistant to add a new scheduler because it's very easy to add, very > difficult to get rid of. If we do add BFQ as a legacy scheduler now, > it'll take us years and years to get rid of it again. We should be > moving towards LESS moving parts in the legacy path, not more. Jens, I think you are wrong here and let me try to elaborate on why. 1) We already have legacy schedulers like CFQ, DEADLINE, etc - and most block device drivers are still using the legacy blk interface. To be able to remove the legacy blk layer, all block device drivers must be converted to blkmq - of course. So to reach that goal, we will not only need to evolve blkmq to allow scheduling (at least for single queue devices), but we also need to convert *all* block device drivers to blkmq. For sure this will take *years* and not months. More important, when the transition to blkmq has been completed, then there is absolutely no difference (from effort point of view) in removing the legacy blk layer - no matter if we have BFQ in there or not. I do understand if you have concern from maintenance point of view, as I assume you would rather focus on evolving blkmq, than care about legacy blk code. So, would it help if Paolo volunteers to maintain the BFQ code in the meantime? 2) While we work on evolving blkmq and convert block device drivers to it, BFQ could as a separate legacy scheduler, help *lots* of Linux users to get a significant improved experience. Should we really prevent them from that? I think you block maintainer guys, really need to consider this fact. 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. > > We can keep having this discussion every few years, but I think we'd > both prefer to make some actual progress here. It's perfectly fine to > add an interface for a single queue interface for an IO scheduler for > blk-mq, since we don't care too much about scalability there. And that > won't take years, that should be a few weeks. Retrofitting BFQ on top of > that should not be hard either. That can co-exist with a real multiqueue > scheduler as well, something that's geared towards some fairness for > faster devices. That's really great news! I hope we get a possibility to meet and discuss the plans for this at Kernel summit/Linux Plumbers the next week! > > -- > Jens Axboe Kind regards Ulf Hansson -- 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
