about your wiki page on I/O schedulers and BFQ

Rafael David Tinoco rafaeldtinoco at ubuntu.com
Thu Jul 18 20:53:50 UTC 2019


Hello Paolo,

I'm looping the kernel team mailing list,just in case, that might help
in the discussion.

Best,
Rafael

On Thu, Jul 18, 2019 at 9:12 AM Paolo Valente <paolo.valente at linaro.org> wrote:
>
> Hi,
> 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
> scheduler).
>
> 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
> benchmarks.
>
> 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,
> Paolo
>
> [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/
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



More information about the ubuntu-devel mailing list