> Il giorno 5 mar 2019, alle ore 17:18, stan <upaitag@xxxxxxxx> ha scritto: > > On Tue, 5 Mar 2019 14:07:15 +0000 > Alan Jenkins <alan.christopher.jenkins@xxxxxxxxx> wrote: > >> On 13/12/2018, Laura Abbott <labbott@xxxxxxxxxx> wrote: >>> >>> Thanks for starting this discussion. Based on this thread and >>> other discussions, I'm going to see about enabling BFQ for >>> 4.21. Once 4.21-rc1 comes out (i.e. almost all configs should >>> be in) we can review the settings and see if anything needs >>> to be adjusted. If I get some time before then (i.e. before >>> I leave for holiday) I'll see if I can change the defaults. >>> >>> Laura >> >> Are there any more up-to-date details on this? Specifically I am >> wondering if there will be any separate package providing udev rules, >> that people should be aware of, if they want to provide testing of 5.0 >> kernels for Fedora. > > I've been using the 5.0 kernels locally compiled and optimized for my > hardware with bfq enabled. I don't have multi thread hardware. The > performance has been comparable to cfq, or slightly worse. > Subjective. I started testing 5.0 today too, with incredibly bad performance, on an old Intel Core i7-2760QM@2.40GHz. I found out the bottleneck to be the CPU (about 7x slowdown). After reporting this issue to some Linaro guys (in CC), I've been suggested a tiresome bisection w.r.t. 4.20 (4.20 which works with no issue). I hope someone will show up with the cause of the problem, relieving me of this burden :) 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; For any question, I'll be glad to answer, if I can, Paolo > And there could be other software changes affecting this. > > I've recently also started using the gcc kernel-stack plugin to clean > stack on return from kernel calls, and didn't really notice any effect > on performance in normal usage. > _______________________________________________ > kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
