On Wed, Oct 3, 2018 at 9:05 AM Artem Bityutskiy <dedekind1@xxxxxxxxx> wrote: > On Wed, 2018-10-03 at 08:29 +0200, Paolo Valente wrote: > > So, I do understand your need for conservativeness, but, after so much > > evidence on single-queue devices, and so many years! :), what's the > > point in keeping Linux worse for virtually everybody, by default? > > Sounds like what we just need a mechanism for the device (ubi block in > this case) to select the I/O scheduler. I doubt enhancing the default > scheduler selection logic in 'elevator.c' is the right answer. Just > give the driver authority to override the defaults. This might be true in the wider sense (like for what scheduler to select for an NVME device with N channels) but $SUBJECT is just trying to select BFQ (if available) for devices with one and only one hardware queue. That is AFAICT the only reasonable choice for anything with just one hardware queue as things stand right now. I have a slight reservation for the weird outliers like loopdev, which has "one hardware queue" (.nr_hw_queues == 1) though this makes no sense at all. So I would like to know what people think about that. Maybe we should have .nr_queues and .nr_hw_queues where the former is the number of logical queues and the latter the actual number of hardware queues. Yours, Linus Walleij
