Il giorno 03 ott 2018, alle ore 09:42, Damien Le Moal =

[off-list ref] ha scritto:

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

quoted

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

wrote:

quoted

quoted

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

quoted

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

much

quoted

quoted

quoted

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

=20
Sounds like what we just need a mechanism for the device (ubi block =

in

quoted

quoted

this case) to select the I/O scheduler. I doubt enhancing the =

default

quoted

quoted

scheduler selection logic in 'elevator.c' is the right answer. Just
give the driver authority to override the defaults.

=20
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.
=20
That is AFAICT the only reasonable choice for anything with just
one hardware queue as things stand right now.
=20
I have a slight reservation for the weird outliers like loopdev, =

which

quoted

has "one hardware queue" (.nr_hw_queues =3D=3D 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.

=20
There is another class of outliers: host-managed SMR disks (SATA and =

SCSI,

definitely single hw queue). For these, using mq-deadline is mandatory =

in many

cases in order to guarantee sequential write command delivery to the =

device

driver. Having the default changed to bfq, which as far as I know is =

not SMR

friendly (can sequential writes within a single zone be reordered ?) =

is asking

for troubles (unaligned write errors showing up).
=20

Hi Damien,
actually I have followed threads on SMR device, and have already looked
into this.  I'm sorry for not having mentioned it in my first reply.

My plan is to simply port this feature from mq-deadline to bfq.  It
should be really straightforward, especially after the testing you did
through mq-deadline.  Even if I'm missing some less trivial hidden
issue, I guess it won't be impossible to address.

If it may be useful for the outcome of this thread, I'm willing to
raise the priority of this change to bfq.

A while back, we already had this discussion with Jens and Christoph =

on the list

to allow device drivers to set a sensible default I/O scheduler for =

devices with

"special needs" (e.g. host-managed SMR). At the time, the conclusion =

was that

udev (or something alike in userland) is better suited to set a =

correct scheduler.

=20
Of note also is that host-managed like sequential zone devices are =

also likely

to show up soon with the work being done in the NVMe standard on the =

new "Zoned

namespace" feature proposal. These devices will also require a =

scheduler like

mq-deadline guaranteeing per-zone in-order delivery of sequential =

write

requests. Looking only at the number of queues of the device is not =

enough to

choose the best (most reasonnable/appropriate) scheduler.
=20

Until bfq simply handles SMR devices too.

Thanks,
Paolo

--=20
Damien Le Moal
Western Digital Research