Thursday, 18 July 2019

Re: about your wiki page on I/O schedulers and BFQ

Hello Paolo,

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


On Thu, Jul 18, 2019 at 9:12 AM Paolo Valente <> 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]
> [2]
> [3]
> [4]
> [5]
> --
> ubuntu-devel mailing list
> Modify settings or unsubscribe at:

ubuntu-devel mailing list
Modify settings or unsubscribe at: