include CK patch set (BFS)

Bug #424927 reported by whwi on 2009-09-05
This bug affects 34 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Declined for Karmic by Brian Murray
Declined for Lucid by Jeremy Foshee
Declined for Maverick by Jeremy Foshee

Bug Description

The CK patch set is intended to improve desktop interactivity performance. The biggest change is the inclusion of the Brain Fuck Scheduler or BFS:

For Karmic:

For Lucid:

For support and general discussion, please use this forum thread:

new desktop scheduler

can this inculded in karmic kernel ?

arky (arky) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at I have classified this bug as a bug in linux.

When reporting bugs in the future please use apport, either via the appropriate application's "Help -> Report a Problem" menu or using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at

affects: ubuntu → linux (Ubuntu)
Alex Ivasyuv (industral) wrote :

Actually, there is no BFS in repository, so arky asks you to view links provided by him, and apply patch to kernel for using new scheduler.
Here are links to the popular Russian social blog, where guys installed BFS and it got positive feedbacks.

and in English:

There is no package associate as it's Linux kernel at all.
Maybe this issue ought to be assigned to the Linux kernel Ubuntu maintainer?

If you need any help with testing/etc I would help.

Ivan Stetsenko (stetzen) wrote :

I'm not sure if the BFS should be included in the default desktop kernel, but an optional BFS kernel will be extremely important for testing purposes. If the testing on Karmik will show significant performance increase and will be stable enough, it may be enabled by default in 10.04

Changed in linux (Ubuntu):
status: New → Confirmed
Tomáš Myšík (gapon) wrote :

It would be nice to have a PPA for kernel with this scheduler.

Tomáš Myšík (gapon) wrote :
Alex Ivasyuv (industral) wrote :
Evgeny Kuznetsov (nekr0z) wrote :

I tried compiling a kernel *.deb patched with BFS, but it failed to install. If someone succeeds compiling a *.deb of it, it may be a sound idea to put it in a PPA for thorough testing. But it definitely is a bad idea to put it in repositories without deep tests.

Wes Garner (wesgarner) on 2009-09-24
tags: added: needs-packaging
Brian Murray (brian-murray) wrote :

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification,, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

summary: - include Brain fuck Scheduler
+ [needs-packaging] include Brain fuck Scheduler
Changed in linux (Ubuntu):
importance: Undecided → Wishlist
Artur Rona (ari-tczew) on 2009-10-06
tags: added: patch
removed: needs-packaging
Darxus (darxus) wrote :

"Darxus it's built on mainline so it has to be gpl2" - con, author, #ck,, Tue Oct 6 00:26:00 EDT 2009.

Darxus (darxus) wrote :

I'm getting ABI errors. How do I do an ABI bump? says to skip ABI, will that work for building a package that might end up in the repositories?

Darxus (darxus) wrote :

Ah, the problem was that debuild was wiping the update I had done to the changelog via dch -i. Why?

Darxus (darxus) wrote :

linux-image-2.6.31-11-generic gives me an error with this patch, but not without this patch.

But the error is in a file the patch doesn't touch:

kernel/power/snapshot.c:1338: error: expected expression before ')' token

Any suggestions?

Darxus (darxus) wrote :

The line is:

  if (info->version_code != LINUX_VERSION_CODE)

So LINUX_VERSION_CODE is probably not defined?

Darxus (darxus) wrote :

It looks like the error is due to include/linux/version.h not being created, and this file is where LINUX_VERSION_CODE is defined. It is created when I manually run "make defconfig prepare".

Any idea why it's not being created?

Darxus (darxus) wrote :

version.h is created as debian/build/linux/version.h. The first time I found it, it contained "#define LINUX_VERSION_CODE" (empty), which would cause the first compile error I posted about. But now I can't reproduce it.

It looks like AUTOBUILD=1 in debian.master/rules.d/ will actually disable the ABI and module checks that have been uncooperative.

Darxus (darxus) wrote :

It looks like I mostly did it:
deb karmic main

I still need to figure out how to make nvidia drivers work with it, possibly just an ABI bump. And figure out what needs to be done to change the package name. But it builds, uploads to LP, and two of the three architectures have built successfully there, so I expect by the time most of you read this all three will have built successfully.

This conflicts with the main kernel, unfortunately, so to uninstall it:
aptitude purge linux-image-2.6.31-12-generic
aptitude install linux-image-generic

Darxus (darxus) wrote :

I got the nvidia module to load by rebooting into the new bfs patched kernel and manually rebuilding the module via dkms:

sudo dkms remove -m nvidia -v 185.18.36 -k 2.6.31-12-generic
sudo dkms build -m nvidia -v 185.18.36 -k 2.6.31-12-generic
sudo dkms install -m nvidia -v 185.18.36 -k 2.6.31-12-generic

I wonder if this is a dkms bug. But it might be reasonable to require an ABI bump after such patching for this to work. Although a better failure mode would be good.

I'm trying an ABI bump.

When booting into the bfs patched kernel, I recommend selecting the recovery mode to avoid the perpetual flickering uselessness (<a href="">LP: #431166</a>) with which you are currently presented when your video driver fails to load. Select the option to drop to a root shell, and then run "telinit 3" to get into a more usable multi-user state.

Darxus (darxus) on 2009-10-10
Changed in linux (Ubuntu):
assignee: nobody → Darxus (darxus)
Darxus (darxus) wrote :

What else needs to be done to get this in the ubuntu lucid and karmic-backports universe archives?
deb karmic main

I just uploaded linux-bfs version 2.6.31-13bfs1.43, so that should be built in my ppa some time today.

To install you'll probably want to do something like this after the new version
 finishes building:

sudo echo "deb karmic main" >> /etc/apt/sources.list
sudo aptitude update
sudo aptitude install linux-bfs-doc linux-bfs-headers-2.6.31-13bfs1 linux-bfs-headers-2.6.31-13bfs1-generic linux-bfs-image-2.6.31-13bfs1-generic linux-bfs-libc-dev

Ignore the 64 vs. 32 bit stuff in the debdiff, those files are automatically generated during build, and I think there presence is a bug in the linux source package (not one I created).

Darxus (darxus) wrote :

The changes from the linux source package are only:

1) Renaming from linux to linux-bfs.
2) Disabling ABI and modules checks.
3) Renaming the source orig tarball (linux to linux-bfs).
4) Changing the linux to linux-bfs on the first line of debian*/changelog (both are necessary).
5) Applying

1 and 2 are in the attached patch.

Renaming was a pain, and it would be nice if it were a less manual task. I think fixing this wouldn't be hard, since most of the relevant files already have a variable defining the source package name, it's just unnecessarily hard coded lots of places.

Darxus (darxus) wrote :

Built. Also did the meta package, so you can install with:

sudo echo "deb karmic main" >> /etc/apt/sources.list
sudo aptitude update
sudo aptitude install linux-bfs linux-bfs-headers-generic

Please test.

I installed 2.6.31-12.41bfs1 (before the renaming into linux-bfs) on my 9.04 installation, Thinkpad X31.
I've only been running it for a bit over a day and so far it has worked great, I havn't noticed a single problem.

I'll post back when I've been running it longer.

Quartz (ghexsel) wrote :

Runs fine of my HP laptop Thurion 64bit running Karmic 64. Trying on a quad-core Intel to see if it helps with non-responsive IDEs while Java appservers run.

Darxus (darxus) wrote :

I'm planning to drop my linux-bfs package in favor of my freshly built linux-bfs-bfq packages:

BFQ is an I/O scheduler that is faster than mainline's CFQ:

Please test.

Susan Cragin (susancragin) wrote :

Will there be a version of bfs-bfq in the repository? If there is one now, I can't find it.
I tested the bfs scheduler.
My impressions.
VERY fast boot-up.
VERY slow bringing up Dragon NaturallySpeaking running under wine.
Good performance of DNS once it comes up. Right now I run linux-rt and Studio because DNS is very sensitive to latency. My impression was that DNS ran as well but not better.
(I'm a one-trick pony.)

Darxus (darxus) wrote :

Susan: Yes, I expect it to go into the universe archive of Lucid as soon as the Lucid archives open, which will be soon after the Karmic release, which happens on the 29th. It's way too late in the Karmic release cycle to include. I think it is also likely to get into karmic-backports, which would be your best option. It is not currently in the archives, only my ppa.

You can use Lucid as soon as the archives open, but it will be an early Alpha testing version of the entire release at that point, and it's important that you understand what that means (likely to break). Lucid will be released in April 2010.

There is also the option of running Karmic with the linux-bfs-bfq packages pinned to Lucid:

You should try prepending the command you use to start dragon naturally speaking with "schedtool -I -e" while using BFS. This will give it (basically) all the CPU it can use before it even considers other processes. This is generally recommended for all sound and UI apps (pulseaudio, music players, video players, X, and your window manager (including compiz)). schedtool is in the schedtool package.

Referring to anything other than the Domain Name System as DNS is very confusing, even immediately after mentioning Dragon NaturallySpeaking :)

Thank you for your feedback, I've passed it along to Con.

Susan Cragin (susancragin) wrote :

Breaking systems are my favorite kind. I'll be on Lucid the day after the repos open.
If you do one for pae I may be able to test that, too.

Darxus (darxus) wrote :

Susan: Excellent, thanks. My package is a patched version of the linux source package, which builds most of the kernel related packages, including pae. 20 binary .debs.

summary: - [needs-packaging] include Brain fuck Scheduler
+ include Brain fuck Scheduler

Packages updated to ubuntu kernel 2.6.31-14 and BFS v0.304.

I haven't done the meta packages yet.

lessoffensive (lessoffensive) wrote :

Thank you for packaging this, Darxus! I've been testing these patches today and find the interactivity to have increased quite a great deal with an overall feeling of general speed improvement and without the massive slow downs I've experienced before. I'm still playing around with it to determine if there are any performance regressions I can notice (typing into this input box in firefox actually briefly pauses every few seconds leaving me about 4-5 letters behind at times--I haven't noticed anything else). I would definitely put my support behind at least a further investigation of these patches for being included into the mainline ubuntu.

xir (simonbennie) wrote :

Right i'm now using BFS (from darxus's repo), it is crazy responsive, i mean sheesh this thing really has a notable difference in nautilus. I'm going to start looking into doing some benchmarking between ubuntu default and this BFS.

There seem to be a lot more cpu interrupts coming from the kernel according to powertop, this could be a serious problem if you are trying to keep power usage low on a laptop. i'm getting over 35% of all interrupts since the patch. Has this kernel had any other tweaks, i.e is it now a 1000hz kernel with dynamic ticks off?

I'm attaching my boot-charts before and after the new kernel, this for the most part is a clean system (i.e a new install since karmic-RC hit). My hard drive seems to be worked harder during the boot process, but i still get a 4 second delay for boot.

xir (simonbennie) wrote :


Darxus (darxus) wrote :

xir: No, the only modifications to the kernel are the two patches. The ubuntu main linux packages and my patched stuff copies the .config used for building to /boot/config*, so you can diff them.

Benchmarking UI responsiveness is apparently a challenging problem. If you come up with a good way to show solid numbers that represent your experience with nautilus, people will be interested.

Just a note: CPU percentage usage is never to be trusted.

xir (simonbennie) wrote :


Sorry if my post was confusing i was comparing the kernel interrupts using power-top. With BFS enabled there are over 400 interupts per second. Without i sit at 90 interupts per second.

i.e from powertop " 58.8% (733.4) <kernel IPI> : Rescheduling interrupts "

This really could be a battery drainer as it will keep the cpu from entering the C6 state.

I just tried some browser benchmarking (i.e peacekeeper and google v8) and there is quite literally nor difference. I'm planning to retry whilst doing some compiling in order to test how well the scheduler manages the two.

Darxus (darxus) wrote :

xir: All my kernel configs, from the main packages and mine, include "CONFIG_NO_HZ=y", which is apparently good for battery life, and against the recommendations for BFS.

Darxus (darxus) wrote :

xir: Your post was not confusing.

I found the recommendations I was talking about:

Configure your kernel with 1000Hz, preempt ON and disable dynamic ticks."

I did not do this, and am not currently planning to.

xir (simonbennie) wrote :

Right ok, i've seen the same high interrupt rate from the kernel happen before when using a 1000hz kernel, which is why i asked.

I'll recheck these interrupt rates on another laptop when i can, if this is still the case BFS most certainly wouldn't be a good option for laptop users especially those with chips that are C6 capable, ie. intel core 2 ULV range.

Darxus (darxus) wrote :

"on my laptop the battery lasts longer with bfs" - Con, author of BFS

Daniel Hollocher (chogydan) wrote :

FWIW, the WINE regression is talked about here:

I just found this page. I'm excited to try this out!

21 comments hidden view all 101 comments
Darxus (darxus) wrote :

Unassigned myself because I've taken way too long. Still planning to work on it.

Changed in linux (Ubuntu):
assignee: Darxus (darxus) → nobody
Quartz (ghexsel) wrote :

"Kolivas has released a new set of patches this morning that are "designed to improve system responsiveness and interactivity with specific emphasis on the desktop." There are 13 patches he has made available that can be applied against the freshly released Linux 2.6.33 kernel. "

Daniel Hollocher (chogydan) wrote :

hey folks, I've taken a stab at updating my ppa. I also tried to do the meta package, so you may be able to just install linux-ck-generic. It is still building; hopefully it all works!

Daniel Hollocher (chogydan) wrote :

... and several builds later, it seems to be working. I'm running the lucid kernel on karmic. Let me know if you have problems.
FYI: I don't know anything about configuring the kernel, so I picked 1000Hz and 896mB for all the questions. For the most part, that is the defaults, but there were two that defaulted to 100Hz, and as such, changing those two to 1000 was the only change I made. Is that good?

description: updated
summary: - include Brain fuck Scheduler
+ include Brain f#%k Scheduler

why change the summary to something nobody ever will get a search hit on? The thing is called Brain Fuck Scheduler and not f#%k... do you really think fuck is such a bad word that you cant live with the knowledge that it exists in a bug summary?

xir (simonbennie) wrote :

i agree. Changing the name serves no useful purpose. The schedulers full name should be used for clarity. Take it up with the dev if its a real issue, he may change it.

Susan Cragin (susancragin) wrote :

My vote is for keeping fuck the way it is. However, here are thoughts:
Modifying a swear word usually means replacing only the vowel.
f*ck would be more appropriate, and more elegant.
There was a good rock group called the Cunts, they just couldn't get any publicity.
Brain Fuck Scheduler is included in the summary often enough to make it come up on Google.
I think ask the developer. He may want it called the BFS Scheduler, or something equally duplicative. And he may not want it called after himself. The scheduler is just one part of it now. The project is bigger than that because it includes bfs and doesn't it still include bfk?
By the way, I downloaded Daniel's kernel, etc., and am running it without a problem.

Quartz (ghexsel) wrote :

My vote (although I'm not sure this is a democracy) would be to use the acronym. Whenever I search, I'm not going to type the whole name anyway, might as well make the title illustrative, like "Include a kernel with BFS/BFQ support", or maybe "Include a kernel with Kolivas' interactivity patches (BFS/BFQ/etc)".

Daniel Hollocher (chogydan) wrote :

I actually, by sheer coincidence, was in the same chat as duanedesign. He wasn't focused on this bug, and was just looking to help out in general. We don't have to read much into it. But since it is here, I will take responsibility for it for the time being.

I like to view censorship as an opportunity to improve language since the language being censored typically isn't descriptive. Usually schedulers are named after the underlying strategy used to schedule. BFS, OTOH, is named after CKs disagreements with the kernel developers, which isn't that informative. Darxus has already been moving towards using the name of ck patchset, so I think we can keep going that direction. But I also want to work in the full uncensored name, since that is what everyone refers to. Anyway, I'll just do it.

summary: - include Brain f#%k Scheduler
+ include CK patch set (BFS)
description: updated
duderonomy (patmcsweeny) wrote :

Can anyone confirm whether or not the BFS patches will be in any of the repositories in the near future?

Darxus (darxus) wrote :

Duderonomy: I haven't looked at Daniel Hollocher's packages much, but at a brief glance it looks like it could get in the archives pretty quickly with a... what do you call them, sponsor?

Daniel Hollocher (chogydan) wrote :

Personally, I'm not sure if these packages could get into the repositories. If there was an automated process, then it could work, but I have to update the packages somewhat manually every time.

I have uploaded -16 in anticipation of the beta release. If I did everything perfect, it will be built by the end of today, and tomorrow I will update the meta package. This package has the nouveau drivers incorporated right in there, so... I don't know! People have been having troubles with that. I am crossing my fingers.

anabelli (anabelli) wrote :

very possibily OT:
the annoying thing with ubuntu is that as soon as you get out of the Path (not using network manager, using thunderbird intead of evolution, etc..) bad and annoying things start to happen.

if you keep your system up to date, you're sure that in grub's kernel list the -ck line is going to end up second to the main line.

Is there any kind of gnome app that lets you chose the order of the different flavours of installed kernels in grub's list? if not, could someone help me thinking out the proper design for such a little and, imo, handy app?

Andrei Dziahel (develop7) wrote :

>>Is there any kind of gnome app that lets you chose the order of the different flavours of installed kernels in grub's list?
@andrea-abelli, there is, just issue sudo aptitude install startupmanager

Andrei Dziahel (develop7) wrote :

Oops, disregard #75 — startupmanager can't *reorder* grub menu entries. Sorry for confusing.

Quartz (ghexsel) wrote :

You can configure the default boot kernel, set by order (for instance, always the top one), or by name.

It goes more or less like (you have to google for details)

vi /etc/default/grub
change GRUB_DEFAULT=0 value to wanted kernel (position or name)
run update-grub to update

anabelli (anabelli) wrote :

Thanks for your answer.
I meant some kind of app that can "remember" my choice:
something that could let me decide the order of the different types of kernel.
I want the -ck line to be the default choice, after a dist-upgrade, even if a newer vanilla kernel was installed.

I'm willing to code it if necessary, has anyone any idea of a proper design for such an app?

Quartz (ghexsel) wrote :

The solution I indicated will do that, you just need to value of GRUB_DEFAULT to be the exact string of the kernel name (as displayed in the grub menu).

More info (Google is your friend - just don't trust your life to it ;)

anabelli (anabelli) wrote :

ok .. this way you can chose only the default one and not the order of the list. but I'm sure there's a simple way to do it and that I'll find it.

Daniel Hollocher (chogydan) wrote :

Hey guys, I created a forum topic to split up the conversation. Long bug reports are bad bug reports, but long forum posts are good forum posts. Ideally I would like to see any discussion about how to package and configure the ck patches stay on the bug report, and support and testing discussions be moved to the forum.

I still need to push out another update as I mis-configured the amd64-generic to have only 250HZ instead of the recommended 1000HZ. I'm waiting to see if there are any further general kernel updates.

Quartz (ghexsel) wrote :


description: updated
Atanas Atanasov (thenasko) wrote :

Has anyone compiled the kernel for Maverick?

Jeremy Foshee (jeremyfoshee) wrote :

Declining the Maverick specific nomination for now and leaving this open against the actively developed Ubuntu kernel (which happens to be Maverick at this time). Will re-open the nomination should a fix be narrowed down which we can confirm specifically resolves this issue in Maverick.

In this instance, unless this goes to upstream stable, it is unlikely that it will make its way into the Ubuntu Kernel.


lal lop (lalop-lmao) wrote :


The patch worked almost perfectly on my Vaio Z, but after installing it the brightness shortcuts Fn+F5-F6 stopped working on my ubuntu (both this kernel and the generic kernal version). The volume shortcuts still work, and I can change the brightness manually via power manager, but that's very annoying. Any idea how to diagnose this?

Daniel Hollocher (chogydan) wrote :

Hey folks, I've been meaning to update ya'll where I'm at. I tried to switch over to git, but I ran into an error and gave up somewhat quickly. I would still like to switch over to git in the long run, since I think that will make the package more in sync with Ubuntu proper. It takes such a long time to build the kernel, so it really takes awhile trying to figure out what the issue is.

Since the git thing didn't work out and I have upgraded to maverick, I am dropping lucid. If someone else is running lucid, and would like to do it, I can give you my notes. (includes directions to apt-get source the kernel, apply the patches, then upload to a ppa)

I also have learned that we should be renaming the kernel flavors, appending the ck name, and not renaming the package. I think that might fix the header issue raised on the forums, but it may not fix the backports drivers issue.

My attention has been diverted a bit, so it may take me awhile to get to these issues. Hibernate hasn't been working for me, except with the tuxonice kernel, so I haven't been running the ck patches myself. I also found that choosing the conservative cpu freq governor gives me a much bigger performance boost than the ck patches, atm.

Also, Im happy to see that ck has a website now, where he is testing more ideas for his patches. If I get things sorted out, maybe I will be able to facilitate greater testing in that regard.

Daniel Hollocher (chogydan) wrote :

FYI: The packaging has changed and so has the name. Instead of changing the name of the package, the name of the flavours is changed. Ie, linux-ck-image-generic is now linux-image-generic-ck

Daniel Hollocher (chogydan) wrote :

Here are my notes for packaging via changing the flavours rather than changing the package name. It drops the renaming patch, and uses several seds and for loops to make the needed changes. This one is geared toward lucid. I do have one geared toward maverick, but the lucid one is slightly more interesting.

Daniel Hollocher (chogydan) wrote :

Hey folks,
I've put the latest experimental ck patch as -ckexperimental into my ppa. Is this kind of testing interesting to anyone? If so, where is the best place to announce such builds?

Please leave your comments on the forum thread.

Quartz (ghexsel) wrote :

What's more "experimental" about this patch than the other ones?

Although I agree this is not the best place for a long discussion or a long list of announcements, I hardly know the place for a non-standard packaging announcement...

Daniel Hollocher (chogydan) wrote :

It occurred to me that maybe this should be a project rather than a bug-report+forum-post.

Susan Cragin (susancragin) wrote :

This would be a very cool project, especially since it could be a special-purpose Ferrari for a few of us.
I have something that needs highest speed, lowest latency, and security NOT an issue.
And will start testing Monday.

Susan Cragin (susancragin) wrote :

If that is similar to the autogroup patch, the BFS scheduler is not compatible with cpu cgroups.

Darxus (darxus) wrote :

That "~200 Line Linux Kernel Patch That Does Wonders", actually "automated per tty task groups", is included in Natty:

Con doesn't like it.

Daniel Hollocher (chogydan) wrote :

FYI, I have the 400 patch building for natty. I won't be putting together a maverick build until I notice an ABI bump. I don't track the ABI at all, so I think it is safer that way. (I'm running the natty kernel on maverick anyway)

Regarding my earlier comments, I do think that having a project page would facilitate our communication better. The mailing list would just work better, and bug reports would allow tracking of issues. We could have bug reports which track certain testing methods / test cases, if people get into that. For now, I'm not going to do anything. I'm going to focus on keeping my ppa page uptodate, and leave the "project" idea for the future.

I'm also going to nix the idea of trying to post ck's testing patches. I feel like my turn around time wouldn't be fast enough to be useful to ck. So I'm just sticking with the stable bfs releases.

Anyway, it looks like ck is opening up his work to wider review. I would appreciate links to any interesting discussion / articles that folks come across.

Quartz (ghexsel) wrote :

Does Kolivas post the patches to a mailing list of his own? Maybe this could be announced in the same list (Ubuntu is, after all, one of the distros with highest market share...).

Daniel Hollocher (chogydan) wrote :

He has a blog! I didn't mention that.

Daniel Hollocher (chogydan) wrote :

Hey folks, so I think it makes sense to wrap up this bug at some point. I've created a team here:

I thought it would be nice to have a bug tracker, but a team with a mailing list might be all that we need.

I'm going to leave everything as is for now, and if moving to a team continues to make sense to me after awhile, I will close out this bug and the forums thread, and invite everyone to join the team/mailing list.

The most up-to-date PPA seems to be:

(has oneiric builds)

Brad Figg (brad-figg) on 2012-03-29
tags: added: kt-worked
Tim Gardner (timg-tpi) on 2012-10-02
Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Displaying first 40 and last 40 comments. View all 101 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers