On 2018/10/03 16:18, Linus Walleij wrote:=0A=

On Wed, Oct 3, 2018 at 9:05 AM Artem Bityutskiy [off-list ref] wro=

te:=0A=

quoted

On Wed, 2018-10-03 at 08:29 +0200, Paolo Valente wrote:=0A=

quoted

So, I do understand your need for conservativeness, but, after so much=

=0A=

quoted

quoted

evidence on single-queue devices, and so many years! :), what's the=0A=
point in keeping Linux worse for virtually everybody, by default?=0A=

=0A=
Sounds like what we just need a mechanism for the device (ubi block in=

=0A=

quoted

this case) to select the I/O scheduler. I doubt enhancing the default=0A=
scheduler selection logic in 'elevator.c' is the right answer. Just=0A=
give the driver authority to override the defaults.=0A=

=0A=
This might be true in the wider sense (like for what scheduler to=0A=
select for an NVME device with N channels) but $SUBJECT is just=0A=
trying to select BFQ (if available) for devices with one and only one=0A=
hardware queue.=0A=
=0A=
That is AFAICT the only reasonable choice for anything with just=0A=
one hardware queue as things stand right now.=0A=
=0A=
I have a slight reservation for the weird outliers like loopdev, which=0A=
has "one hardware queue" (.nr_hw_queues =3D=3D 1) though this=0A=
makes no sense at all. So I would like to know what people think=0A=
about that. Maybe we should have .nr_queues and .nr_hw_queues=0A=
where the former is the number of logical queues and the latter=0A=
the actual number of hardware queues.=0A=

=0A=
There is another class of outliers: host-managed SMR disks (SATA and SCSI,=
=0A=
definitely single hw queue). For these, using mq-deadline is mandatory in m=
any=0A=
cases in order to guarantee sequential write command delivery to the device=
=0A=
driver. Having the default changed to bfq, which as far as I know is not SM=
R=0A=
friendly (can sequential writes within a single zone be reordered ?) is ask=
ing=0A=
for troubles (unaligned write errors showing up).=0A=
=0A=
A while back, we already had this discussion with Jens and Christoph on the=
 list=0A=
to allow device drivers to set a sensible default I/O scheduler for devices=
 with=0A=
"special needs" (e.g. host-managed SMR). At the time, the conclusion was th=
at=0A=
udev (or something alike in userland) is better suited to set a correct sch=
eduler.=0A=
=0A=
Of note also is that host-managed like sequential zone devices are also lik=
ely=0A=
to show up soon with the work being done in the NVMe standard on the new "Z=
oned=0A=
namespace" feature proposal. These devices will also require a scheduler li=
ke=0A=
mq-deadline guaranteeing per-zone in-order delivery of sequential write=0A=
requests. Looking only at the number of queues of the device is not enough =
to=0A=
choose the best (most reasonnable/appropriate) scheduler.=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=