Monday, November 22, 2010

The Linux Speed Boost!

Oh my, it has been a while since I visited my Blog. While there were few worthy posts which I should have blogged about, that never happened. Recently, when I came across a post on OMG Ubuntu, about a new kernel patch which supposedly speeds up Linux, I just had to try it out. Its been a while since I've compiled my own kernel (these days I rely on stock Ubuntu), but after seeing the results myself thought it was very much blog worthy for me to share with you.

First off, for the impatient or the unmotivated, let me point you to another post on Phoronix, which contains a video showing the night and day difference this patch brings. If your still not impatient, then you could wait for 2.6.38, which will hopefully have this, considering Linus's supportive comments, regarding the patch.

Ok now for the glory details on getting this patch up and running. I did this on Ubuntu 10.10 but it should work the same for other Debian and Debian like distros as well as other popular distros with minor tweaks.

Get the kernel

Download the kernel 2.6.37 from At the time of writing, 2.6.37 had not been officially released and was at RC2

cd /usr/src
tar jxf linux-2.6.37-rc2.tar.bz2

Get the patch

The patch published by Mike Galbraith can also be copied from here. Save it to a file called kernelboost.patch in /usr/src/kernelboost.patch

Dry-run and Apply patch

Go to the kernel directory and dry-run the patch to make sure it applies cleanly. If everything is ok, go ahead and apply for real ;)

cd /usr/src/linux-2.6.37-rc2
patch --dry-run -p1 < /usr/src/kernelboost.patch

#if everything is ok
patch -p1 < /usr/src/kernelboost.patch

Configure and compile the kernel

This is a generic step of compiling the kernel. The configuring step can be performed using your current config file. Make sure you enable the patch by answering Y to CONFIG_SCHED_AUTOGROUP.

cp /boot/config-2.6.35-22-generic /usr/src/linux-2.6.37-rc2/.config
make oldconfig
make modules_install
make install

If your on Ubuntu, I'd recommend installing the kernel the Debian way instead of using the make, make modules_install and make install steps.

apt-get install kernel-package fakeroot build-essential ncurses-dev
cd /usr/src/linux-2.6.37-rc2
sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion
make-kpkg clean
CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers

cd ..

You should find two .debs in /usr/src related to the new custom kernel. Install using dpkg -i or by double clicking on the deb from the file manager. Once you reboot to the new kernel everything should be all set. Just to double check make sure :

cat /proc/sys/kernel/sched_autogroup_enabled

If it has 1 then its enabled. You can echo 0 > /proc/sys/kernel/sched_autogroup_enabled to disable the scheduler on the fly.

I noticed a significant improvement when trying to play BioShock from Steam using CrossOver Games. With the previous kernel, I had a lot of lag, especially with Compiz turned on. For instance, when moving the mouse to look around, it was very much discrete. Now I notice things are smoother and the game is much playable.

Your experience may be different depending on how you use the computer. Chances are that if you tend to use CPU hogging applications such as playing games or watching HD movies, you will notice an improvement.

Till next time a blog worthy event that excites me happens~

Monday, February 08, 2010

Splitting a git repo

Its been almost an year since I last blogged and what can I say, micro-blogging killed blogging for me. Even micro-blogging has got to a point, I don't do as much as I used to. Perhaps the end of web 2.0 or perhaps I'm getting too old for this :)

Anyhow, getting back to the subject of this quick post, it seems splitting a git repo into two separate git repos is somewhat obscure and required a bit of googling around. Fortunately I came across this great blog post, but wanted to summarize it in one place (the author made me look at several pages to put it together).

Say I have a git project called foo.repo which had a subdirectory called bar, that I now want to make its own separate git project called bar.repo.

Current state


target state



Step 1 : Clone existing repo as desired repo on the local clone

$ git clone --no-hardlinks foo.repo bar.repo

Step 2: Filter-branch and reset to exclude other files, so they can be pruned:

$ cd bar.repo
$ git filter-branch --subdirectory-filter bar HEAD -- --all
$ git reset --hard
$ git gc --aggressive
$ git prune

Step 3: Create new empty repo on git server

$ mkdir /var/git/bar.git
$ cd /var/git/bar.git
$ git --bare init

Step 4: Back on the local machine, replace remote origin to point to new repo

$ cd bar.repo
$ git remote rm origin
$ git remote add origin git@git-server:bar.repo
$ git push origin master

Step 5: Remove bar directory from original foo.repo

$ git filter-branch --tree-filter "rm -rf bar" --prune-empty HEAD

or supposed to be faster, I haven't tried
$ git filter-branch --index-filter "git rm -r -f --cached --ignore-unmatch bar" --prune-empty HEAD