[ANNOUNCE] BFQ-v2 for 2.6.37
Paolo Valente
I am happy to announce BFQ-v2, which contains the NCQ-related feature I
mentioned in one of my previous emails, plus a few other things.
According to my tests on 2.6.37 (extended and run with the valuable help
of Mauro Andreolini), none of these features is paid with a loss of
aggregate throughput with respect to BFQ-v1.
* BFQ-v2 provides the same low-latency guarantees with and without
NCQ. In other terms, differently from CFQ, latency guarantees are
preserved also in presence of NCQ. For example: under a heavy workload
and with BFQ-v2, it takes about two seconds to start konsole with and
without NCQ on a medium-rate disk, whereas, under CFQ, it takes about 21
seconds without NCQ and about 2940 seconds (49 minutes) if NCQ is enabled.
* The latency for interactive applications is about halved with
respect to BFQ-v1.
* When the low_latency tunable is set, also soft real-time
applications now enjoy reduced latency (audio and video players/servers,
music, ...). More in detail, when low-latency was enabled with BFQ-v1,
only interactive applications were privileged, at the expense of
non-interactive ones. This caused the latency experienced by soft
real-time applications to grow, and become comparable to the one
guaranteed by CFQ. Now, also soft real-time applications are properly
privileged. For example, under heavy load and while other commands are
repeatedly invoked, a video player enjoys about five-time-lower
frame-drop rate than with CFQ.
* A very little minimum bandwidth is now guaranteed to the Idle
IO-scheduling class also when the other classes are backlogged, just to
prevent the former from starving. In some situations, this starvation in
turn happened to cause critical processes to block waiting for the disk
indefinitely, which led to system livelock. For example, if konsole was
repeatedly started and closed while two files were being read in
parallel, then, after a few invocations, Xorg hung and login attempts
from textual consoles blocked indefinitely (2.6.37, Ubuntu 10.10,
files--the ones read in parallel--stored on a different partition w.r.t.
to konsole and libraries). The actual bug is probably outside the block
layer; however, differently from CFQ, with BFQ-v2 the system apparently
does not hang anymore in this and other medium/heavy-load situations.
You can find the full patchset for vanilla here:
http://algo.ing.unimo.it/people/paolo/disk_sched/patches/2.6.37-v2/
and the incremental patch here:
http://algo.ing.unimo.it/people/paolo/disk_sched/patches/previous_versions_revisions/incremental_patches/from_2.6.37-v1_to_2.6.37-v2/
I am leaving the content of the directory 2.6.37 temporarily unchanged
(it still contains BFQ-v1). Yet in a few days I will:
. rename 2.6.37 as 2.6.37-v1
. create a link 2.6.37 pointing to 2.6.37-v2.
Please update any relevant link. After a few weeks I will move 2.6.37-v1
into the directory previous_versions_revisions.
As usual, any feedback is more than welcome. I am already working on the
port to 2.6.38.
I hope this new version of BFQ will work well and you will enjoy it,
Paolo
kernelOfTruth
Paolo ! :)
Thanks to you and also Mauro Andreolini
gotta try this out this evening ^^
Palatinux
--
Yours sincerely, Met vriendelijke groet, Mit freundlichen Grüßen
Palatinux
Palatinux
kernelOfTruth
but the system feels snappier
On Mar 4, 1:50 am, Palatinux <fortressli...@gmail.com> wrote:
> Speeds up an allmodconfig kernel compile with 5%. Even better :)
>