Fedora Switching To The BFQ I/O Scheduler For Better Responsiveness & Throughput

[phoronix]

Phoronix: Fedora Switching To The BFQ I/O Scheduler For Better Responsiveness & Throughput

Following Chromebooks switching to BFQ and other distributions weighing this I/O scheduler for better responsiveness while maintaining good throughput capabilities, beginning with Fedora 31 there will be BFQ used as well...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Switching-To-BFQ

[RussianNeuroMancer]

Is bfq-mq works with eMMC for anyone? How bfq-mq can be enabled specifically for eMMC?

[Jumbotron]

Well...2 of the Big 3 (Red Hat/IBM and Suse) have switched to BFQ. So has Google. Ok Ubuntu, time to crap or get off the pot.

[Britoid]

Well...2 of the Big 3 (Red Hat/IBM and Suse) have switched to BFQ. So has Google. Ok Ubuntu, time to crap or get off the pot.

Canonical will make their own scheduler, claim it's better, not support any other scheduler. Then in 5 years time when they can't maintain it anymore, will switch to BFQ.

[geearf]

Latest BFQ seems to work well with NVME if I read this correctly: https://algo.ing.unimo.it/people/paolo/BFQ/results.php

and his email to Ubuntu

a few days ago I ran benchmarks (on Ubuntu) also with one of the fastest consumer-grade NVMe SSDs: a Samsung SSD 970 PRO. Results [4] can be summarized as follows. Throughput with BFQ is about the same as with the other I/O schedulers (it couldn't be higher, because this kind of drives just wants the scheduler to stay as aside as possible, when it comes to throughput). But, in the presence of writes as background workload, start-up times with BFQ are at least 16 times as low as with the other I/O schedulers. In absolute terms, gnome-terminal starts in ~1.8 seconds with BFQ, while it takes at least 28.7 (!) seconds with the other I/O schedulers. Finally, only with BFQ, no frame gets lost in video-playing benchmarks.

[Grogan]

That's not appropriate for all usage patterns... I sure as Hell don't like BFQ. It makes build jobs take longer, and creeps me out with little i/o delays when exiting shells and stuff. I have no need of those gyrations, mq-deadline is the most sensible of those multiqueue schedulers.

It should not be the default i/o scheduler.

[paolo]

Latest BFQ seems to work well with NVME if I read this correctly: https://algo.ing.unimo.it/people/paolo/BFQ/results.php

and his email to Ubuntu

I have proposed to leave NVMe out for the moment, as a precaution. The idea is to add also NVMe if everything goes well with this preliminary step.

[paolo]

That's not appropriate for all usage patterns... I sure as Hell don't like BFQ. It makes build jobs take longer, and creeps me out with little i/o delays when exiting shells and stuff. I have no need of those gyrations, mq-deadline is the most sensible of those multiqueue schedulers.

It should not be the default i/o scheduler.

It has hard to understand what is going wrong from anecdotes. Could you run this quick test and report results?

git clone https://github.com/Algodev-github/S && S/run_multiple_benchmarks/test_responsiveness.sh

[AndyChow]

Is bfq-mq works with eMMC for anyone? How bfq-mq can be enabled specifically for eMMC?

https://wiki.archlinux.org/index.php/Improving_performance#Changing_I/O_scheduler

Just make a rule in udev, and specify the device has to have a name of the "mmcblk" type.

[Rallos Zek]

BFQ is still after many years still prone to slow performance and system lockups. its even worse on HDDs, Stick with Deadline or Noop for your health.