Fresh RCs for 18.04.3 -- Please Test
paul.richards at gmail.com
Wed Aug 7 16:09:51 UTC 2019
Brilliant answer, thanks!
I found it particularly interesting to learn that there are default mq
schedulers picked by the kernel itself. My incorrect understanding had
been that the kernel would always default to “none” in the mq framework and
it was up to distros to provide udev rules.
On Wed, 7 Aug 2019 at 15:24, Colin Ian King <colin.king at canonical.com>
> 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 -
> > ) ?
> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-release