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
There's a long standing bug which prevents FC14 to boot on most EFI systems
Would a knowledgeable kernel developer please review the patch for
drivers/video/efifb.c and commit it?
Thanks in advance for your help
Could someone with enough karma rebuild krb5-auth-dialog 0.16 for F-13
(this is in relation to bug #597669). The 0.15 is leaking memory like
there is no tomorrow and I'm not getting much traction from the assignee
of the bug...
(intentionally breaking thread)
Toshio Kuratomi (a.badger(a)gmail.com) said:
> Maybe I should start a new thread since this isn't really a bug, but it is
> a blocker -- we need to get some packaging guidelines out for systemd.
> I think that the last message on the subject was this one:
> Could I get a reply as to whether that looks right?
- At the moment, /bin/systemctl is in systemd-units. (I think this
is a bug. Filed.)
- As long as we're still shipping upstart, the sysv scripts would still
need included, and would still need to be set up with chkconfig the
> As noted in the post, I'm not sure if the outlined procedure correctly
> implements level 1.
I believe it does.
> We should probably also have the scriptlets for implementing level 3 for the
> things basic to the system that require that.
My reading of your mail is different - the case we want to handle is case
#2 (installation of something that starts by default - dbus, NM, etc.)
As I understand it, they would be the same, with the addition of:
if [ 0$1 -eq ]; then
/bin/systemctl enable <foo.service>
with foo.service having the appropriate [Install] stanza that says where it
should start up. As with SysV scripts, we generally do not start services
by default, so this is rare.
Case #3 that you mentioned is something I don't think we have in Fedora -
we never start services on package installation.
This, however, is just packaging guidelines. From readng the thread, there
are many things that I think people would like covered with systemd before
they would feel comfortable with it. So, I'm going to attempt to quantify
what would need to be tested and verified. This document focuses on
backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes,
- System boots successfully to GUI, when configured.
- System boots successfully to text mode, when configured.
- System properly handles being passed [1-5], 'single', 'S', 's', '-s',
booting to the appropriate 'runlevel' (0 and 6 can still work,
but they're sort of pointless anyway) When booted in this manner,
'5' will bring up a GUI, and '3' will not.
SINGLE USER MODE
- Exiting single user mode properly returns to the default state.
- single-user mode output is correctly displayed on the console.
- plymouth is shown on startup.
- plymouth is quit correctly.
- plymouth is shown on shutdown.
- 'esc' to show details still functions in plymouth.
- an equivalent to /var/log/boot.log still exists, and is populated
(can be normal syslog)
- plymouth transition from grub -> boot -> X is seamless for KMS cards,
similar to Fedora 13.
- telinit  does the proper thing.
- the 'runlevel' command displays correct output if we are in a target
that is aliased to a runlevel.
- 'halt' shuts down, but does not poweroff.
-- 'halt' supports -p, to power off.
- 'poweroff' shuts down, and powers off.
- 'reboot' shuts down and reboots.
- 'halt', 'poweroff', 'reboot' all support '-f', to force the action.
- 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and
the audit layer.
- 'shutdown' shall support the following arguments in a compatible manner:
'r', 'h', 'H', 'P', 'c', 'k', <time>.
- 'telinit' does not error when passed '[Qq]' (to reload its configuration)
and '[Uu]' to re-exec itself. It can optionally make systemd do a similar
action, if valid.
- init shall support a mechanism to re-exec itself to not cause dirty
inodes on shutdown; initscripts will use this method on shutdown.
- the kbdrequest job currently in systemd will be disabled for final release.
- 'ctrl-alt-delete' will reboot the system.
- prefdm starts a configured display manager correctly.
- prefdm starts a installed display manager correctly without additional
- ConsoleKit properly logs system start, stop, and restart.
- The ConsoleKit shutdown/reboot/halt methods work as expected.
- Booting with a primary serial console (via console=) automatically
sets up a getty on the console, and sets up securetty to allow for root
- (optional) Booting with secondary serial consoles does the same.
- By default, 6 gettys will be started in text mode, on tty1-6. 5
gettys will be started in GUI mode, on tty2-6.
- getty and X will not be started on the same tty.
- (optional) The number of ttys started can be configurable.
- SELinux automatic relabelling will still function.
- fsck will still function.
- Dropping to an emergency shell in the case where either of these fails
shall still function.
- No AVCs from the init system in normal use.
- No AVCs when executing any of the cases specified here
- systemd shall still function if booted with selinux=0.
- Guidelines for packaging systemd units shall be formalized.
- The behavior when both systemd units and SysV services are present on
the system shall be defined. This includes defined behavior when a
service appears to be 'enabled' for SysV links while 'disabled' for
systemd (and vice-versa).
- The syntax of systemd units shall be frozen for the release (all future
releases? Some set number of releases?)
- Running 'chkconfig <foo> <(null)|on|off>' on a service managed by systemd
will return the correct code/perform an appropriate action.
- Running 'service <foo> <start|stop|...>' on a service managed by systemd
will perform the appropriate action (via systemctl), and return
- Running '/etc/init.d/<foo> <start|stop|...>' will not break the systemd
environment, while still performing the action specified, and shall return
- Booting a system shall achieve a similar result as booting in upstart:
-- The same set of services will be started.
-- The services shall function the same.
-- The same set of devices and filesystems shall be mounted.
-- The same set of devices and filesystems shall be fscked.
- rc.local will run as the final service on bootup.
- gettys will not start until after rc.local.
- prefdm will start coincident to gettys (earlier?)
- The files and paths used by systemd shall be frozen for future releases.
- The basic syntax of systemd commands shall be frozen for future releases.
- The syntax of systemd units shall be frozen for future releases.
ASSORTED RANDOM CONFIGURATIONS
- The system shall properly function with:
-- encrypted /
-- encrypted non-/
-- nfs /
-- iSCSI /
-- LDAP user information
-- IPA/AD user information
-- NIS user information
-- ext* filesystems
-- btrfs filesystems
-- xfs filesystems
ANY REMAINING UPSTART JOBS
- All packaged upstart jobs are modified to have some SysV or systemd-native
... that's all I have at the moment. I'm sure I'm missing something.