16

I just installed Linux kernel version 4.12 on Ubuntu 17.04 using ukuu (Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility).

The thing is, when I check the available I/O schedulers, I can't seem to find the BFQ nor the Kyber I/O scheduler :

cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]

So how to use one of the new schedulers in this Linux version ?

21

I'm not in Ubuntu, but what I did in Fedora may help you.

BFQ is a blk-mq (Multi-Queue Block IO Queueing Mechanism) scheduler, so you need to enable blk-mq at boot time, edit your /etc/default/grub file and add scsi_mod.use_blk_mq=1 to your GRUB_CMDLINE_LINUX, this is my grub file, as an example:

GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=false
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="quiet vt.global_cursor_default=0 scsi_mod.use_blk_mq=1"
GRUB_DISABLE_RECOVERY="true"

After that, you must update your grub. On Fedora we have to use sudo grub2-mkconfig -o /path/to/grub.cfg, which varies depending on the boot method. On Ubuntu, you can simply run:

sudo update-grub

Reboot, and if you get this:

cat /sys/block/sda/queue/scheduler
[mq-deadline] none

Probably your kernel was compiled with BFQ as a module, and this can be the case also for Kyber.

sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none

You can add it at boot time by adding a /etc/modules-load.d/bfq.conf file containing bfq.

It is important to note that enabling blk_mq turn it impossible to use non blk_mq schedulers, so you will lose noop cfq and the non mq deadline

Apparently blk_mq scheduling system is not supporting elevator flags in grub, udev rules can be used instead, with a bonus of offering a more grained control.

Create /etc/udev/rules.d/60-scheduler.rules if it did not exist and add:

ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"

As pointed here if needed you can distinguish between rotational (HDDs) and non-rotational (SSDs) devices in udev rules using the attribute ATTR{queue/rotational}. Be aware that Paolo Valente, BFQ developer, pointed in LinuxCon Europe that BFQ can be a better choice than the noop or deadline schedulers in terms of low latency guaranties, what makes a good advice to use it for SSDs too.

Paolo's comparison: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be

Save it, and reload and trigger udev rules:

sudo udevadm control --reload
sudo udevadm trigger
  • 3
    I just want to note: don't do this on computers with Linux < 4.15 that you expect to be able to suspend-to-ram; < 4.15 will hang all IO on resume because they lack the "safe SCSI quiescing" fixes. – Ivan Kozik Dec 2 '17 at 23:42
  • You may also have problems on kernel 4.14 where enabling blk-mq seems to give a kernel "oops" right at the beginning of loading the kernel on some systems (it's not a full stop panic, just a null dereference inside the kernel). You might miss it if you're not looking for it but if you're paranoid it could be a sign that something is broken. – CR. Jan 21 '18 at 14:14
  • 1
    I'd suggest using a slightly more accurate udev rule. When I tried the one shown here, udev tried to set the scheduler for some devices whose names match that pattern, but aren't SCSI block devices that can use the BFQ scheduler. The rule I ended up with is this: ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq" It avoids pattern matching against names of devices, which makes the matching more accurate. It won't match partition devices because they don't have the "queue/scheduler" attribute. – Dan Moulding Mar 9 '18 at 17:16
  • 3
    Also important to note is that kernels 4.15-4.16 suffer from a pretty severe bug where updating the partition scheme of a drive while using BFQ can lead to a complete I/O lock-up. Cf.: lkml.org/lkml/2017/12/1/80 – Glutanimate Apr 3 '18 at 1:40
1

To extend great RomuloPBenedetti answer:

You can test, if bfq scheduler is actually available on particular device by using PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'" in udev rule. This will effectually replace DRIVERS=="sd|sr" and just not fire if one forgot scsi_mod.use_blk_mq=1

Trivia:

  • PROGRAM - Execute a program to determine whether there is a match; the key is true if the program returns successfully; If no absolute path is given, the program is expected to live in /lib/udev.
  • $sys - The sysfs mount point (/sys).
  • $devpath - The devpath of the device (/devices/pci/...).

protected by Community Jun 29 '18 at 10:21

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.