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

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 [1]. 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 [Array]] interactivity patches [forum [1]] 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 [1]] [story [1]], 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 [2] 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 [2]]. After installing the latest -mm kernel, you'll be able to give this functionality a try.

interview [2]] 4G/4G highmem patch [3]. 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 [3]]. 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 [4] 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.

story [4]], and on using patches to upgrade 2.6 [story [4]].

http://kernel.org/mirrors/ [5].

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

this comment [6] 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 [6] 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.

grub [7] [manual [8]] or lilo [9] [howto [10]], 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.