Linux 4.15 I/O Scheduler Tests: BFQ, CFQ, Kyber

[Licaon]

I'm leaving BFQ disabled for now after what happened with kernel 4.12 when it was first enabled. After a suspend/resume cycle the system would become unusable due to all io related syscalls hanging.

Interesting, saw a lot of this for a while, blamed it on dying hardware though (albeit the hard-drive has a slow wakeup now on 4.14 even without suspend/resume). Looks like I need to test this w/ and w/o BFQ too. Thanks for the heads up.

[waxhead]

I wonder how much the underlying filesystem potentially affect the outcome of the tests. Yes, I am aware that this is a I/O scheduler test, but it would be very interesting to see the exact same thing with different filesystems. Perhaps some of them benefit better from a certain scheduler than others.

[starshipeleven]

cat /sys/block/sdX/queue/scheduler
echo <SCHEDULER> > /sys/block/sdX/queue/scheduler

You can change the scheduler permanently by using

elevator=<SCHEDULER>

in your kernel parameters.

This is true for older schedulers, the new-gen ones like kyber and BFQ (multqueque schedulers) need a different spell.

https://bfq.teambelgium.net/

As of Linux kernel version 4.12, BFQ has been accepted into the mainline kernel. However, it is only available for blk-mq (Multi-Queue Block) so you will have to pass the kernel boot option scsi_mod.use_blk_mq=1 and manually select BFQ by issuing the following for each of your devices:

echo bfq > /sys/block/sdX/queue/scheduler (replace X appropriately)

Or you can create the file 20-block.rules in /etc/udev/rules.d with the below in it and it will set BFQ as default during boot.

ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/scheduler}="bfq"

(replace "bfq" with "kyber" or other schedulers, to see the list, cat /sys/block/sdX/queue/scheduler AFTER you rebooted with the kernel boot options above)

[Holograph]

Anyone using Kyber? Any comments on it? I always see people talking about BFQ, but seemingly not Kyber. Is there little interest in it? Do you guys think it's not very good?

[paolo]

Thanks Michael for these new tests. Unfortunately they confirm my (partially) bad results with BFQ on start-up times. The reason is that, while my fixes/improvements did improve things, 4.15 came with new block-layer issues, which almost completely offset my improvements. If you are curious, problems are caused by how blk-mq distributes tags for I/O requests. I have just finished preparing a bunch of patches to counter these new 4.15 issues, and results on my machines are apparently extremely good. If everything runs fine, you'll see these improvements in 4.16 (hoping that 4.16 will not introduce brand new problems). Or much before in my bfq-mq development branch.

[starshipeleven]

Anyone using Kyber? Any comments on it? I always see people talking about BFQ, but seemingly not Kyber. Is there little interest in it? Do you guys think it's not very good?

Kyber is something that appeared out of thin air (Facebook project addressing a server-y specific usecase), while BFQ is around since a long while and has always been aimed at end user devices.

I'm currently using Kyber while I wait for BFQ to stabilize (more for the whole block mq scheduler subsystem to stabilize, as paolo said).

It's better than deadline on legacy schedulers, but it is still easy to lag the UI. I'm using btrfs and mechanical drives on a desktop PC. On my laptop (2 SSDs, btrfs RAID1) I don't see any lagging when I transfer files around from slower media (unlike with legacy schedulers).

So I keep using my script that tries to find processes with high IO and sets them to low IO priority. Quite frankly if most DEs set file transfers and similar jobs with low IO priority it would be bearable even with legacy schedulers.

EDIT: by popular demand, I uploaded the script here https://pastebin.com/r7zJEP2k
It's probably not perfect, and may eat your kittens. Use at your own risk.