On Tue, 5 Mar 2019 17:42:12 +0100 Paolo Valente paolo.valente@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.