Fresh RCs for 18.04.3 -- Please Test

[Colin Ian King]

Hi Paul,


> I had a look at the same image as Ian:
> 
> 72491db7ef6f3cd4b085b9fe1f232345 *bionic-desktop-amd64.iso
> 
> I was mostly curious about single queue devices now defaulting to the
> multi queue IO scheduler framework (previously they used the legacy IO
> schedulers - https://lwn.net/Articles/767987/ ).  I was also
> interested to see how the udev rules might work to select an
> appropriate multiqueue scheduler for nvme / ssd / hdd.
> 
> What I found:
> 
> 1. There are no udev rules for different devices, but my ssd and hdd
> defaulted to a sensible multiqueue scheduler anyway (both using
> mq-deadline).

Multi-queue devices now default to using the multiqueue mq-deadline
scheduler. This is a kernel driven choice based on the device being a
multiqueue device, there are no udev rules in this choice whatsoever.

> 
> 2. With 18.04.2 my SATA disks used the legacy "cfq" scheduler by
> default, and with 18.04.3 they use "mq-deadline" by default.
> 
> 
> So my quesions are:
> 
> 1. Will the transition to a multi-queue IO scheduler default be called
> out in the release notes for 18.04.3?

Indeed, this needs to be documented.


> There are two possible
> surprises for users.  First, as I understand it the spiritual
> successor to "cfq" should be "bfq", not "mq-deadline".  Second, any
> 18.04.2 users who have set grub boot parameters to select which legacy
> IO scheduler to use will find their parameter no longer working as
> they now need to configure multi-queue parameters instead.

I suspect BFQ will replace CFQ as default as some point in the future,
however, at the time of testing for the HWE kernel being used for
18.04.3 we found a few corner cases where it didn't quite work as we
expected performance-wise, so we chose not to use it for that kernel.

It's hard to select the perfect default I/O scheduler since we need the
"best" choice for different file systems (ext2/3/4, xfs, btrfs etc) for
SSD, HDDs and NVME devices. The choice made was based on tens of
hundreds of tests covering 25 different synthetic fio tests on various
devices with all the available I/O schedulers (7 for this particular
kernel).  Each I/O scheduler as pros/cons, so there are always going to
be occasions where the default is not perfect for some use-cases.

> 
> 2. Will the Ubuntu "IOSchedulers" wiki page be updated wrt 18.04.3?  (
> https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers )  It says
> things like "Prior to Ubuntu 19.10..", which will need updated.  (I
> think this wiki page was already uncorrect, surely it should have said
> "Prior to Ubuntu 19.04" ?)

Yes, I will get that updated. Thanks for pointing this out.

> 
> 3. Just for my own curiosity, how does Ubuntu 18.04.3 select a default
> mq scheduler without udev rules like other distros do (e.g. Arch -
> https://wiki.archlinux.org/index.php?title=Improving_performance&oldid=578436#Changing_I/O_scheduler
> ) ?
> 

This is handled in the kernel in block/elevator.c, the specific block
drivers for each device and the various I/O scheduling code in the block
directory. If the device is multi-queue cable then the flags for this
device are set with the BLK_MQ_F_NO_SCHED bit so the multi-queue default
is selected, otherwise we fall back to the non-multi-queue default.

Hope that clarifies things,

Colin