|[ANNOUNCE] bfq-v3r1 for .38, .39, 3.0 and 3.1||paolo||11/7/11 1:30 PM|
once again I am not announcing just a port to 3.1, but a new version of bfq.
More precisely, it is a revision of v3, available for 2.6.38, 2.6.39,
23.0 and 3.1. This revision contains, basically, an important bug fix
(see below the list of new features).
Curiously, this bug interacted with the block layer in some obscure way
that improved latencies :)
So, after removing the bug, latencies got worse. We had to investigate
the problem, and fortunately it seems we have solved it by adding the
additional mechanism described below. This mechanism did not yield just
the same latencies as before: actually, it allows bfq to achieve even
lower latencies. Unfortunately, the latency of interactive applications
is still, occasionally, unusually high (it happens, for example, about
one time out of ten command-startup attempts). But, leaving out these
outliers, the minimum, average and maximum latency is now much improved
(from two to ten times lower than before).
This is the full list of the fixes and new features:
As usual, Arianna has prepared patches for every possible transition.
I hope bfq will continue to serve you well,
|Re: bfq-v3r1 for .38, .39, 3.0 and 3.1||richardw||11/24/11 9:48 AM|
Are there any plans to bring BFQ into mainline?
|Re: bfq-v3r1 for .38, .39, 3.0 and 3.1||Bryce||11/27/11 2:52 AM|
can you please describe in more detail that special case where
Great work, by the way. Looking forward for the 3.2 port... or even a
|Re: [Bulk] Re: bfq-v3r1 for .38, .39, 3.0 and 3.1||paolo||11/27/11 9:19 AM|
Il 24/11/2011 18.48, richardw ha scritto:
It is an old, yet short story. BFQ received a warm welcome when we first
introduced bfq to lkml some years ago.
But the maintainer of the block layer, Jens Axboe, raised two issues
that prevented a possible push to mainline:
1) in his opinion, bfq is conceptually too complex to be easily
maintained by people other than the authors
2) he thinks there must be only one disk scheduler; with regard to this,
I have been told that he would be willing to review a 'patch-to-cfq'
version of bfq, but I am afraid that turning bfq into just a patch to
cfq is unfeasible
Now or then I will retry and submit the last version of bfq.
|Re: bfq-v3r1 for .38, .39, 3.0 and 3.1||paolo||11/27/11 9:37 AM|
Il 27/11/2011 11.52, Bryce Lynch ha scritto:Thanks for your offer of help.
The situation seems exactly that vague. If you repeat the same identical
test ten times (e.g., launch xterm with cold caches while ten large
files are being read sequentially), then, for nine times, the
startup-time is about the same as if the disk is idle, but one instance
will take much more.
Of course something changes across the ten runs. Maybe something in the
I am happy about your interest in bfq, and hope that the new versions
will not disappoint you :)