[ANNOUNCE] bfq-v3r1 for .38, .39, 3.0 and 3.1

94 views
Skip to first unread message

Paolo Valente

unread,
Nov 7, 2011, 4:30:16 PM11/7/11
to bfq-i...@googlegroups.com
Hi,
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:
- Fixed an important request-dispatch bug causing occasional IO hangs
- Added a new mechanism to reduce the latency of low-bw async queues.
This should reduce the latency of also the sync queues synchronized with
the above async queues.
- Fixed a minor bug in iocontext locking (port of commits 9b50902 and
3181faa
from CFQ).

As usual, Arianna has prepared patches for every possible transition.

I hope bfq will continue to serve you well,
Paolo

richardw

unread,
Nov 24, 2011, 12:48:03 PM11/24/11
to bfq-iosched
Hi,

Are there any plans to bring BFQ into mainline?
If so, why was it rejected? ;)

Thanks,
//richard

Bryce Lynch

unread,
Nov 27, 2011, 5:52:38 AM11/27/11
to bfq-iosched
Hello,

can you please describe in more detail that special case where
latencies are unusually high? "About one time out of ten command-
startup attempts" seems a bit vague, perhaps others here can help
identify and fix the bug.

Great work, by the way. Looking forward for the 3.2 port... or even a
new version :-)

Cheers,

Bryce

Paolo Valente

unread,
Nov 27, 2011, 12:19:27 PM11/27/11
to bfq-i...@googlegroups.com
Il 24/11/2011 18.48, richardw ha scritto:
> Hi,

>
> Are there any plans to bring BFQ into mainline?
> If so, why was it rejected? ;)
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.

Paolo
>
> Thanks,
> //richard
>

Paolo Valente

unread,
Nov 27, 2011, 12:37:55 PM11/27/11
to bfq-i...@googlegroups.com
Il 27/11/2011 11.52, Bryce Lynch ha scritto:
> Hello,
>
> can you please describe in more detail that special case where
> latencies are unusually high? "About one time out of ten command-
> startup attempts" seems a bit vague, perhaps others here can help
> identify and fix the bug.
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
(state of the) block layer. Most certainly the state of the disk drive
differs at the beginning of each run (internal cache, position of the
head), and this may cause some small variations of the timings that can,
in their turn, interfere with the scheduler.
I have not yet had the time to thoroughly investigate this problem. Any
help is more than welcome.


>
> Great work, by the way. Looking forward for the 3.2 port... or even a
> new version :-)

I am happy about your interest in bfq, and hope that the new versions
will not disappoint you :)

Paolo
>
> Cheers,
>
> Bryce
>
>

Reply all
Reply to author
Forward
0 new messages