I have been working for a few years (with Fabio Checconi) on a disk
scheduler providing definitely lower latencies than cfq, as well as a
higher throughput with most of the test workloads we used (or the same
throughput as cfq with the other workloads). We named this scheduler
bfq (budget fair queueing). I hope this is the right list for announcing
One of the things we measured in our tests is the cold-cache execution
time of a command as, e.g., "bash -c exit", "xterm /bin/true" or
"konsole -e /bin/true", while the disk was also accessed by different
combinations of sequential, or random, readers and/or
writers. Depending on which of these background workloads was used,
these execution times were five to nine times lower with bfq under
2.6.32. Under 2.6.35 they were instead from six to fourteen times
lower. The highest price paid for these lower latencies was a 20% loss
of aggregated disk throughput for konsole in case of background
workloads made only of sequential requests (due to the fact that bfq
of course privileges, more than cfq, the seeky IO needed to load
konsole and its dependencies). In contrast, with shorter commands, as
bash or xterm, bfq also provided up to 30% higher aggregated
We saw from 15% to 30% higher aggregated throughput also in our
only-aggregated-throughput tests. You can find in  all the details
on our tests and on other nice features of bfq, such as the fact that
it perfectly distributes the disk throughput as desired, independently
of disk physical parameters like, e.g., ZBR. in  you can also find
a detailed description of bfq and a short report on the maturity level
of the code (TODO list), plus all the scripts used for the tests.
The results I mentioned so far have been achieved with the last
version of bfq, released about two months ago as patchsets for 2.6.33
or 2.6.34. From a few days a patchset for 2.6.35 is available too, as
well as a backport to 2.6.32. The latter has been prepared by Mauro
Andreolini, who also helped me a lot with debugging. All these patches
can be found here . Mauro also built a binary kernel package for
current lucid, and hosted it into a PPA, which can be found here .
A few days after being released, this version of bfq has been
introduced as the default disk scheduler in the Zen Kernel. It has
been adopted as the default disk scheduler in Gentoo Linux too. I
also recorded downloads from users with other distributions, as, e.g.,
Ubuntu and ArchLinux. As of now we received only positive feedbacks
from the users.
 Ubuntu PPA: ppa:mauro-andreolini/ubuntu-kernel-bfq
Christopher Aillon <caillon(a)redhat.com> wrote:
> I missed the first notice of this go by, but I use zsh so can play with
> it in the next few days. Can you post the updates so I don't hit the
> same bugs you did?
Sure. Attached. The bugs were mainly with zsh conventions and getting
the sed command for the branch selection corrected.
we use mock for local package build, but it's very slow. now we install
a new host just for mock with 8core, ram disks etc. it seems it still
slow. first of all most of the time mock use only one 1 core of the cpu.
is there any way to speed up different part of the mock build process?
thanks in advance.
ps. anyway is there any better place to discuss it?
Levente "Si vis pacem para bellum!"
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10 seconds to properly add repository, and I don't want to speedup
this process - to prevent Ohloh from accidental DoS).
With best regards, Peter Lemenkov.
I attempted to build a new version of Gimp 2.7.1 using Koji scratch method but
ended up with that result. Here is attached spec file borrowed from Nils as I
wanted to experiment that version along with Design. Can anyone check what went
If someone implement
into the mozilla source, we can easily remove source for the
libraries. And Fedora will be happy. :-)
I'd like to ask for feedback and helping cleaning up an updates policy
How can we clarify the language or the layout of the page to be more
clear? Are there places that it could be more like the existing package
update howto page? Could we be more detailed about what bodhi enforces
and whats just good practice?
Are there other exceptions cases that could be covered that you can
NOTE that this is a draft. I'd like constructive feedback.
If we can get something that looks ok by next week, FESCo would like to
approve this and put it in place.
Please do try and keep technical and constructive in replies, pretty
please? With a cherry on top?
Hi, everyone. So we partly used the proposed new nice-to-have bug
tracking system during the F14 Beta process, and it seemed to go well.
In a quick burst of airport productivity, I've quickly written up a
bunch of proposed new wiki pages and modifications to existing ones to
document the nice-to-have process (and, incidentally, extend
documentation of the blocker process, since we don't seem to have much
of it beyond the blocker meeting SOP right now). All the pages can be
it should be pretty obvious which are new and which are modifications of
existing pages. I hope this is mostly straightforward and
A quick five-minute summary is that we will now have (in fact, we
already do) trackers for nice-to-have bugs for Alpha, Beta and Final
releases as well as trackers for blocker bugs. Bugs on these NTH lists
will be given priority after blocker bugs for QA, devel and releng work
for releases. Fixes for these bugs - and *only* these bugs, if a fix is
to be taken through a freeze, there must be a matching accepted NTH bug
- will be taken through release freezes. Proposing, reviewing and
monitoring NTH bugs will work exactly as it does for blocker bugs, and
mostly happen in the blocker meetings, but of course after consideration
of the blocker lists.
In practice this is a formalization of existing procedure - until F14
Beta, QA and releng did much the same process but entirely informally,
we just kept lists of bugs we'd take fixes for either in our heads or in
the RC creation trac tickets. This process is meant to be more robust,
documented and discoverable.
Some releng SOP pages may require minor updates, I figured I'd leave
that to releng. The process for creating blocker trackers should also be
updated to cover creating NTH trackers (I couldn't find that; poelcat,
where is it?)
Comments, questions, suggestions welcome!
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org