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 ?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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
Method 2
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/…).
Method 3
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
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0