How do we get this magic performance-boosting 200 line patch?
Discussion regarding this specific patch took place on the Ubuntu kernel-team mailing list:
https://lists.ubuntu.com/archives/kernel-team/2010-November/013498.html
But let me try to elaborate even more generically about the best way for any patch to make its way into the Ubuntu kernel...
First, it's the preferred policy of the Ubuntu Kernel Team that patches be submitted and accepted upstream before being pulled into the Ubuntu kernel. It's a large maintenance burden on the Ubuntu Kernel Team to have to maintain out of tree patches. Additionally, if the patch will benefit the entire Kernel Community, it should go upstream first.
Once the patch has been accepted upstream, it will eventually make its way into the Ubuntu kernel automatically. A cherry-pick or pull request could also be made if one so desired, see the page, KernelPatches, for more information.
If the patch needs to be applied as an SRU (stable release update) to a previous Ubuntu release it's best to get the patch accepted into the corresponding upstream stable 2.6.x.y tree. As a part of our normal kernel SRU process, we continually rebase to the latest upstream stable kernel. Thus we would again eventually get the patch automatically.
I've just read the lkml thread and hope I can offer some information - although not about getting the patch into Ubuntu. As a post on the linked Ubuntu list says, it's probably going to be in 2.6.38 anyway.
The patch automatically groups process based on TTYs. There is a lot of discussion/argument on the lkml that says this means it isn't relevant for typical desktop usage - that it makes no difference to interactive applications. The test cases are all based around "start a CPU intensive task from a terminal then look at the responsiveness of another task". So compiling a kernel and trying to watch a video, for example.
That's not to say it's not good, but the general "desktop responsivity improved by an order of magnitude" type headlines could be misleading if you never run CPU intensive tasks connected to a TTY. I could be wrong of course though!
There were some mentions of ways of achieving a very similar result by adding to your bash scripts and allowing all users to create cgroups. This will only work if current Ubuntu kernels have cgroups enabled. The relevant posts are:
- http://marc.info/?l=linux-kernel&m=128993140308849&w=2
- http://marc.info/?l=linux-kernel&m=128993874020246&w=2
Obviously this isn't answering the question, but it could be used to determine whether the patch is as magical as hoped.
How can Ubuntu users get this in a way that's supported?
Emphasis mine. The only way you'll get it in a supported way is by waiting for Ubuntu to pull it into the Ubuntu kernel. As this is really just making it to the kernel mailing list, it's fresh to the point where all testing is fairly anecdotal and I imagine it will be some time before it's ready to be mass-deployed.
Somewhere between the next release and a long time would be my uneducated guess.
But if you're a big boy (or girl) and you can cope with a broken kernel if things go wrong (ie you know how to use grub), you can patch and compile your own kernel.
Download a patch. There are different versions but the best on its own was posted below by another user: http://pavlinux.ru/krnl/sched_autogroup-2.6.36.patch.bz2
Download the kernel source for the version your patch targets. In this case 2.6.36. You can get vanilla (that is original, unmodified by the Ubuntu kernel team) kernel sources from kernel.org and extract it.
Save the patch somewhere and apply it by
cding into the kernel source dir and running:patch -p1 < /path/to/patch(you need thepatchpackage for this... Which I think comes as part ofbuild-essentialif it's not installed by default)And then continue with the rest of the "old fashioned" build process... I really wouldn't bother with the newer methods as they're aimed at Ubuntu/Debian-sanctioned kernel sources... Plus the old way seems easier (to me).
Building kernels isn't hard but you can mess it up if you stray too far from the accepted path. And you won't get official support if things go wrong.
Alternatively, there are more and more kernels emerging with the patch built in (or at least in the source tree, awaiting the next release).
- I believe Zen Kernel has this patch in their tree but I'm not sure if it's in any builds yet.
- The Liquorix Kernel has this baked in now too.
Note: both these kernels (and probably others too) deviate from the Ubuntu way of doing kernels somewhat. You may find (as I did when I moved to Liquorix) that CPU frequency scaling stops working or suspend gets broken. There are usually fixes and workarounds, but chances are you won't get support from AskUbuntu or the rest of the Ubuntu communtiy as we can't check every single kernel out there.