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@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@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
