[ANNOUNCE] bfq for 2.6.35

[Paolo Valente]

Hi,
here is bfq for 2.6.35 :)
I published both a patchset to introduce bfq in 2.6.35 from scratch [1],
and an incremental patch to turn bfq for 2.6.34 to 2.6.35 [2]. The
latter seems to work fine on top of the head of the master branch in
zen.git, of course provided that commit
4966e578ea55c52f5196aaef09ee267381433d2a is first reverted. Should it
make your life easier, I also attached a patch to revert this commit.

I just finished running a few tests.
If I did not make any mistake, the most important result I saw is a
further reduction of the latencies with respect to cfq: the startup
times of xterm and konsole with bfq are now from 6 to 14 times lower
than with cfq.
Also the relative performance in running a kernel make or git
merge/checkout under heavy load seems improved. Finally, for both
schedulers, the results of the aggregated throughput tests are about the
same as under 2.6.34. You can find further details in [3].

Paolo

[1] http://algo.ing.unimo.it/people/paolo/disk_sched/patches/2.6.35/
[2]
http://algo.ing.unimo.it/people/paolo/disk_sched/patches/previous_versions_revisions/incremental_patches/from_2.6.34-to_2.6.35/
[3] http://algo.ing.unimo.it/people/paolo/disk_sched/results.php

[Steven Barrett]

Thank You Paolo!

I added the patches to zen.git... and thanks for including the patch to
undo the temporary commit, that came in useful :)

[Mladen Pejaković]

May I ask what are the chances to see BFQ merged in mainline Linux kernel?

[Lex Rivera]

2010/8/4 Mladen Pejaković <pej...@gmail.com>:

> May I ask what are the chances to see BFQ merged in mainline Linux kernel?
>

I also want to know that. Someone asked in LKML?

[Paolo Valente]

Lex Rivera ha scritto:

> 2010/8/4 Mladen Pejaković <pej...@gmail.com>:
>
>> May I ask what are the chances to see BFQ merged in mainline Linux kernel?
>>
>>
>
> I also want to know that. Someone asked in LKML?

I guess I'm the one that should do it :)
We presented bfq a few years ago in LKML. It received a warm welcome.
But then Jens Axboe essentially said that bfq was conceptually too deep.
BFQ is actually not a trivial toy. However, I did not yet fully
understand how the various heuristic and quasi-formal components of cfq
combine with each other to get fairness or low latencies. Yet my opinion
on this matter is probably not the fairest one :)

In any case, my plan is waiting for you and me to use/test BFQ for some
other weeks, possibly get other feedbacks, and then propose BFQ again
with the additional strength of the new latency/throughput results and
of a user base happy about it. Then I will keep my fingers crossed :)

The other important problem is that I need my time to do the job I am
paid for :)
And my job does not include maintaining bfq, which is unfortunately
lagging behind cfq for many features: simplified dispatch, fail-safe
queue allocation and whatever else is coming. I'm thinking about ways
for getting resources to engage people, or some other solutions. But it
is not easy at all ...
Any suggestion is more than welcome :)

Paolo
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.441 / Virus Database: 271.1.1/3047 - Release Date: 08/03/10 06:35:00
>
>