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.vale...@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
