On Tue, 5 Mar 2019 17:42:12 +0100
Paolo Valente <paolo.valente(a)linaro.org> wrote:
At any rate, let me take this opportunity for updating you guys on
what happened in the last months.
First, server-side, I discovered that the techniques used to guarantee
I/O bandwidth to clients, containers and virtual machines easily
result in throughput losses of up to 90%! So I improved BFQ so as to
make it an alternative solution that brings this loss down to just
10%. Full details in this very recent (today :) ) short article:
http://ow.ly/vsrW50mBAGl
Second, PC-side, I've pushed new commits for the dev version of BFQ
(I'll submit these commits for the production version, probably
tomorrow; so they'll probably be all available from 5.2). These
commits provide the following, measurable performance boost:
- up to ~80% faster application start-up times in the presence of
background workloads
- ~150% throughput boost in one of the nastiest workloads for BFQ the
one generated by dbench. The throughput is finally on pr with any
other I/O scheduler, and most likely equal to the maximum possible
throughput reachable with this test
- elimination of the 18% loss of throughput occurring with only
random reads, w.r.t. to none as I/O scheduler; there is no loss any
more;
This sounds great! Thanks for the update. Looking forward to 5.2.