> Il giorno 06 ott 2016, alle ore 13:57, Austin S. Hemmelgarn > <ahferro...@gmail.com> ha scritto: > > On 2016-10-06 07:03, Mark Brown wrote: >> On Thu, Oct 06, 2016 at 10:04:41AM +0200, Linus Walleij wrote: >>> On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo <t...@kernel.org> wrote: >> >>>> I get that bfq can be a good compromise on most desktop workloads and >>>> behave reasonably well for some server workloads with the slice >>>> expiration mechanism but it really isn't an IO resource partitioning >>>> mechanism. >> >>> Not just desktops, also Android phones. >> >>> So why not have BFQ as a separate scheduling policy upstream, >>> alongside CFQ, deadline and noop? >> >> Right. >> >>> We're already doing the per-usecase Kconfig thing for preemption. >>> But maybe somebody already hates that and want to get rid of it, >>> I don't know. >> >> Hannes also suggested going back to making BFQ a separate scheduler >> rather than replacing CFQ earlier, pointing out that it mitigates >> against the risks of changing CFQ substantially at this point (which >> seems to be the biggest issue here). >> > ISTR that the original argument for this approach essentially amounted to: > 'If it's so much better, why do we need both?'. > > Such an argument is valid only if the new design is better in all respects > (which there isn't sufficient information to decide in this case), or the > negative aspects are worth the improvements (which is too workload specific > to decide for something like this).
All correct, apart from the workload-specific issue, which is not very clear to me. Over the last five years I have not found a single workload for which CFQ is better than BFQ, and none has been suggested. Anyway, leaving aside this fact, IMO the real problem here is that we are in a catch-22: "we want BFQ to replace CFQ, but, since CFQ is legacy code, then you cannot change, and thus replace, CFQ" Thanks, Paolo -- Paolo Valente Algogroup Dipartimento di Scienze Fisiche, Informatiche e Matematiche Via Campi 213/B 41125 Modena - Italy http://algogroup.unimore.it/people/paolo/
