about your wiki page on I/O schedulers and BFQ

Paolo Valente paolo.valente at linaro.org
Wed Jul 17 18:27:19 UTC 2019

this is basically to report outdated statements in your wiki page on
I/O schedulers [1].

The main problematic statement is that BFQ "...  is not ideal for
devices with slow CPUs or high throughput I/O devices" because too
heavy.  BFQ is definitely more sophisticated than any of the other I/O
schedulers.  We have designed it that way to provide an incomparably
better service quality, at a very low overhead.  As reported in [2],
the execution time of BFQ on an old laptop CPU is 0.6 us per I/O
event, against 0.2 us for mq-deadline (which is the lightest Linux I/O

To put these figures into context, BFQ proved to be so good for
"devices with slow CPUs" that, e.g., Chromium OS migrated to BFQ a few
months ago.  In particular, Google crew got convinced by a demo [3] I
made for them, on one of the cheapest and slowest Chromebook on the
market.  In the demo, a fast download is performed.  Without BFQ, the
download makes the device completely unresponsive.  With BFQ, the
device remains as responsive as if it was totally idle.

As for the other part of the statement, "...  not ideal for ...  high
throughput I/O devices", 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

BFQ then provides other important benefits, such as from 5x to 10X
throughput boost in multi-client server workloads [5].

So, is there any chance that the outdated/wrong information on your
wiki page [1] gets updated somehow?  If I may, I'd be glad to update
it myself, after providing you with all the results you may ask.

In addition, why doesn't Ubuntu too consider switching to BFQ as
default I/O scheduler, for all drives that BFQ supports (namely all
drives with a maximum speed not above ~500 KIOPS)?

Looking forward to your feedback,

[1] https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers
[2] https://lwn.net/Articles/784267/
[3] https://youtu.be/w2bREYTe0-0
[4] https://algo.ing.unimo.it/people/paolo/BFQ/results.php
[5] https://www.linaro.org/blog/io-bandwidth-management-for-production-quality-services/

More information about the ubuntu-devel mailing list