20

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 ?

Improve this question

3 Answers 3

Reset to default
29

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
Improve this answer
5
  • 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, 2017 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, 2018 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, 2018 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, 2018 at 1:40
  • You can also echo bfq > /sys/block/sda/queue/scheduler as root. (sudo did not work for me in Ubuntu 18.04) This should make it effective immediately.
    – Rob Audenaerde
    Feb 26, 2020 at 10:46
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/...).
Improve this answer
0

Just want to share with the community of my successful implementation of the recommendations made above by RomuloPBenedetti.

I needed to do this because when I used the command

nice -n 17 tar cf - . | ( cd ${there} ; nice -n 17 tar xvpf - )

for a partition (/DB001_F5 on root device) to partition (/site/DB002_F5 on separate device) mirroring of 250 GB, my system was not usable. I was under the impression that the nice command should have taken care of that ... but it did not!

After implementation, I have very minor delay (1/2 - 1 sec) when switching applications or workspaces or cursor interactions.

Before implementation, the delays were, without joking, of the order of minutes! I was unable to get the immediate response for the mouse or scrolling button, that is needed to even think it was interactive, rather than a "snail-mail" interaction.

Also of note, the transfer before the "tweaks" took about 90 minutes. Afterwards, it took only 48:

29.23user 
902.53system 
47:39.63elapsed 
32%CPU 
(0avgtext+0avgdata 3160maxresident)k

For those who might ask, I had tried the low-latency version of my kernel, but that did not offer the benefit of improved interactive response priority.

My Desktop Configuration My desktop is UbuntuMATE 20.04 LTS.

Linux {myhost} 5.4.0-94-generic #106-Ubuntu SMP 
Thu Jan 6 23:58:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
4 GB RAM
Only HDDs
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .