In a couple of earlier articles, we walked through the process of upgrading to the 2.6.0-test4 kernel [story], and then using a small patch to upgrade to the 2.6.0-test5 kernel [story]. Today we'll continue our patching efforts to upgrade to an even faster feeling and more stable kernel with Andrew Morton's [interview] -mm patchset [forum].

Andrew Morton began releasing his -mm kernel patches a little over a year ago, in the summer of 2002. The -mm tree began as a 90k patch against the 2.5.17 development kernel, merging in the remote kernel debugger, kgdb. By the release of 2.5.18, the -mm patchset had grown to nearly 238k, merging in a wide assortment of fixes and new functionality. As of this writing, the current -mm patchset is 2.6.0-test5-mm3, weighing in at nearly 5 megabytes. Andrew's -mm tree has evolved from a testing ground for numerous new technologies, to a comprehensive patchset that is usually more stable than the mainline 2.6.0-test kernel itself. This bodes well for the future of the 2.6 kernel, as Andrew Morton will soon be the official 2.6 kernel maintainer.

There are numerous reasons you may desire trying Andrew's -mm kernel tree. Stability alone is a good incentive, and scanning the lengthy changelog you'll find a significant number of bug fixes that have been applied. I asked Andrew how the stability of his kernel compares to that of the mainline 2.6.0-test kernel, and he replied that though occasionally new bugs creep in, due to having the latest fixes the -mm tree is generally more stable and up-to-date.

Beyond that, desktop users will be excited to feel the Con Kolivas [interview] interactivity patches [forum] in action, and all of Con's patches are merged into Andrew's patchset. Or, perhaps you're interested in trying Jens Axboe's Complete Fair Queuing disk I/O scheduler [story] [story], also present. And real time OS fans will enjoy the included real time enhancements.

Another enhancement that affects performance but that is already merged into the mainline 2.6.0-test kernel is AIO, or Kernel Asyncronous I/O support. The AIO home page explains, "AIO enables even a single application thread to overlap I/O operations with other processing, by providing an interface for submitting one or more I/O requests in one system call (io_submit()) without waiting for completion, and a separate interface (io_getevents()) to reap completed I/O operations associated with a given completion group." AIO fans will happily find numerous AIO enhancements in Andrew's tree that haven't yet found their way into the mainline 2.6.0-test kernel.

Regular KernelTrap readers will remember Sam Ravnborg's patch allowing one to specify a build directory that's different from where the actual kernel source lives [story]. After installing the latest -mm kernel, you'll be able to give this functionality a try.

Owners of x86 servers with extermely large amounts of RAM will benefit from Ingo Molnar's [interview] 4G/4G highmem patch. If you're not familiar with Ingo's highmem effort, I suggest following the above link to read Ingo's complete description. In a nutshell, in the standard 2.6-test kernel, x86 servers are restricted to 4GB of virtual memory, divided in a 3 to 1 split, with user space getting 3GB and the kernel getting only 1GB. As a server's RAM grows, this limitation becomes a greater and greater bottleneck. With Ingo's 4G/4G patch, it's possible to give the kernel a full 4GB of VM, and to give user space processes each their own 4GB VMs.

Kernel developers are certainly able to make good use of kgdb, the remote kernel debugger which has been merged into Andrew's patchset since the very beginning. I was curious of the implication of Andrew soon to take over the 2.6 stable kernel series that perhaps a kernel debugger will actually make it into a stable Linux kernel, something that Linux creator Linus Torvalds has long refused to do [story]. Andrew commented, "kgdb would need quite some work to make it mergeable, and it's questionable, because if someone is in a position where they need kgdb, they are also in a position where they can add a separate patch."

Finally, another development oriented addition that Andrew recently included is support for compiling the kernel with Intel's IA-64 ECC compiler.

With Andrew Morton to take over the 2.6 stable kernel once Linus moves on to working on the 2.7 development kernel, one might wonder what's going to happen to the -mm patchset. Unfortunately, as of yet this remains an unanswered question. I asked Andrew for input to which he simply replied, "I haven't decided yet." In any case, that's in the future. For now, I recommend that you download Andrew's latest patchset and give it a try! It's quite simple, as you'll see below if you prefer to follow step-by-step directions.

Step 0: Make a backup of important data.
If you're going to be running a development kernel I highly recommend that you have a current backup of any important data.

Step 1: Upgrade to the latest 2.6 kernel
Andrew's patches apply against the latest 2.6 kernel source, so you'll need to download the latest 2.6 kernel source code first. For help on this, please refer to my earlier story about upgrading from 2.4 [story], and on using patches to upgrade 2.6 [story].

Step 2: Obtain Andrew's latest patch.
At the time of this writing, Andrew's latest patch is 2.6.0-test5-mm3. This can be found from your nearest kernel.org mirror by navigating to "/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test5/2.6.0-test5-mm3/".

You can find your nearest mirror at this link: http://kernel.org/mirrors/.

It's recommended that you also download the signature file to verify the patches validity. Find full details on how this is done here.

Step 3: Apply the patch.
Applying the patch to upgrade your source to the -mm tree is a simple one line command. However, I tend to prefer to keep a copy of the old source tree around "just in case", best done utilizing the '-rl' flags with the 'cp' command, creating a hard linked copy as explained in this comment from an earlier story.

Here's what I did to patch my kernel:

   # cd /usr/src
   # mv ~/2.6.0-test5-mm3.bz2 .
   # cp -rl linux-2.6.0-test5 linux-2.6.0-test5-mm3
   # cd linux-2.6.0-test5-mm3
   # bzip2 -dc ../2.6.0-test5-mm3.bz2 | patch -p1

It's the last line that does the actual patching, taken straight out of the README that's in the top level of your Linux kernel source tree. If you're using a *.gz version of the patch, simply replace 'bzip2' with 'gzip' in that command.

Step 4: Cleanup old .o files and dependencies.
Now that your kernel source tree is patched to the latest -mm code, be sure to remove the many old object files and dependencies. This is done with 'make mrproper', as follows:

   # pwd
   /usr/src/linux-2.6.0-test5-mm3
   # make mrproper

Note: If you didn't save your old source tree, be sure to save a copy of your '.config' file before running 'make mrproper'!

Also, some have pointed out that this step should no longer be required thanks to the new build system found in the 2.6 kernel. My reply is two-fold. First, it's not going to hurt anything. And second, the README included with the 2.6 kernel still recommends this step and thus so do I.

Step 5: Configure your new kernel.
This step is made much simpler if you have an already compiled 2.6.0-test kernel. I used my old '.config' configuration file and the text based 'make oldconfig' method as follows:

   # pwd
   /usr/src/linux-2.6.0-test5-mm3
   # cp ../linux-2.6.0-test5/.config .
   # make oldconfig

Most all the options will zoom by, automatically answered based on your existing .config file. You'll only be asked about new options. For example, if upgrading from 2.6.0-test5, you'll see the following four new options:

4 GB kernel-space and 4 GB user-space virtual memory support (X86_4G) [N/y/?] (NEW)
  Suspend-to-Disk Support (PM_DISK) [N/y/?] (NEW) 
  Default resume partition (PM_DISK_PARTITION) [] (NEW)
  Synaptics TouchPad (MOUSE_PS2_SYNAPTICS) [N/y/?] (NEW)

Step 6: Build your new kernel.
To build a new kernel on x86, all you need to type is 'make'. If you've chosen to compile any modules, you'll also need to install them by typing 'make modules_install'. Or, you can string these two commands together: 'make && make modules_install'.

If you're curious about what other 'make' options there are when building your kernel, type 'make help'.

Step 7: Install your new kernel.
Now that you've built your kernel, you need to copy it into place. You'll want to copy this file and your new System.map into /boot. For example:

    # pwd
    /usr/src/linux-2.6.0-test5-mm3
    # mv arch/i386/boot/bzImage /boot/bzImage-2.6.0-test5-mm3 
    # mv System.map /boot/System.map-2.6.0-test5-mm3
    # cd /boot
    # rm System.map
    # ln -s System.map-2.6.0-test5-mm3 System.map 

Having copied your new kernel into place, now you need to configure your boot loader. You're probably using grub [manual] or lilo [howto], refer to the appropriate documentation if you're unsure how your boot loader works.

Step 8: It's still not too late...
It's still not too late to back up any important data on your hard drive...

Step 9: Try your new kernel.
You're now ready to reboot your computer and try out your snappy new 2.6-mm kernel. Give it a try and let us know what you think.