Pages

16 May 2013

417. Briefly: Patching kernel 3.9 with the CK patchset: 3.9-ck-1

Nothing strange here -- basically the same as http://verahill.blogspot.com.au/2013/04/395-ck-kernel-on-debian-and-patching.html but with updated links.

I haven't found a good and succinct description of what the -ck patch set does and that I could link to here, but here's what it says on the Arch -ck page:
"..many Archers elect to use this package for the BFS' excellent desktop interactivity and responsiveness under any load situation. Additionally, the bfs imparts performance gains beyond interactivity"

I don't know if there are objective benchmarks that one can use to demonstrate an improvement in 'responsiveness and interactivity'. Subjectively, however, I feel that there's a slight improvement. You decide for yourself.

Begin here

sudo apt-get install kernel-package fakeroot build-essential ncurses-dev
mkdir ~/tmp
cd ~/tmp
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.9.2.tar.xz
tar xvf linux-3.9.2.tar.xz
cd linux-3.9.2/
wget http://ck.kolivas.org/patches/3.0/3.9/3.9-ck1/patch-3.9-ck1.bz2
bunzip2 patch-3.9-ck1.bz2
patch -p1 < patch-3.9-ck1
patching file arch/powerpc/platforms/cell/spufs/sched.c patching file Documentation/scheduler/sched-BFS.txt patching file Documentation/sysctl/kernel.txt patching file fs/proc/base.c patching file include/linux/init_task.h patching file include/linux/ioprio.h patching file include/linux/sched.h Hunk #6 succeeded at 2738 (offset -10 lines). patching file init/Kconfig patching file init/main.c patching file kernel/delayacct.c patching file kernel/exit.c patching file kernel/posix-cpu-timers.c patching file kernel/sysctl.c patching file lib/Kconfig.debug patching file include/linux/jiffies.h patching file drivers/cpufreq/cpufreq.c patching file drivers/cpufreq/cpufreq_ondemand.c patching file drivers/cpufreq/cpufreq_conservative.c patching file kernel/sched/bfs.c patching file kernel/sched/Makefile patching file include/uapi/linux/sched.h patching file include/linux/sched/rt.h patching file kernel/stop_machine.c patching file include/linux/swap.h patching file mm/memory.c patching file mm/swapfile.c patching file mm/vmscan.c patching file arch/x86/Kconfig patching file kernel/Kconfig.hz patching file kernel/Kconfig.preempt patching file Makefile
make-kpkg clean cat /boot/config-`uname -r`>.config make oldconfig

You might now be asked a long series of questions about how the kernel should be configured (or you might not be -- depending on what kernel version you're currently running). In MOST cases you can select the default option (i.e. hit enter) but you should still read each question and consider it. Making a mistake won't break your computer, so don't be scared.

Next, start the compilation (will take a while):

time fakeroot make-kpkg -j4 --initrd kernel_image kernel_headers
sudo dpkg -i ../linux*3.9-ck*.deb

where 4 is the number of cores on your machine (note: it only has to do with compiling -- you can use the compiled binaries on any number of cores).

Anyway, that's all -- you've now patched, compiled and installed a new kernel. And it didn't even hurt.

7 comments:

  1. Have you tried the new 3.10-rc1 kernel from https://www.kernel.org/ on Debian - it seems to start fast but there is an issue with nvidia, which seems to be this:

    https://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/486858-linux-kernel-3-10-rcx-has-been-released-test-post-your-comments-here.html

    https://devtalk.nvidia.com/default/topic/543728/building-nvidia-driver-on-kernel-3-9-0/

    - the modules do not compile on the new kernel but 3.9, now stable is fine.

    ReplyDelete
    Replies
    1. I haven't, but as it's only rc1 I think it might be worth staying away from it for another 2-3 weeks so that the most egregious issues get hammered out.

      Delete
  2. Thanks, looking forward to this hopefully happening although in retrospect it sometimes looks more straightforward to take a card out of a machine with this colorful history -

    https://www.google.com/search?q=linus+torvalds+nvidia&oq=linus+torvalds+nvidia&aqs=chrome.0.69i57j69i65j0l3j69i62.9169j0&sourceid=chrome&ie=UTF-8

    ReplyDelete
    Replies
    1. There's a somewhat more...nuanced...discussion of the problem with nvidia. I'll see if I can dig up the article and post it here. Anyway, it spells out in great detail exactly why Linus has a beef with nvidia. Essentially it boils down to nvidia receiving credit for work that's mostly done by the kernel devs.

      Anyway, nvidia tends to work ok, but no thanks to the company behind it.

      Delete
    2. This post touches briefly on it: http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.html

      "Still, NVIDIA is benefiting once again from the Linux kernel and X server developers' hard work without themselves contributing anything significant to building the infrastructure that Linux and NVIDIA's driver needs to support graphics hardware both now and in the future.

      NVIDIA gets away with this egotistical behaviour because users praise them and Linux computer manufacturers don't demand open source drivers enough."

      Delete
    3. make-kpkg clean instead of make-kpgk clean :)

      Delete
    4. Good catch. Cheers for pointing it out. Fixed now.

      Delete