Last month many developers were scurrying to prepare for the 2.6.33 merge window (which we’ll cover in the next time). When they weren’t doing that, here are a few of the items that were under discussion, starting with the Big Kernel Lock. As I’ve mentioned before, one of the longer-term goals of the kernel development community is to kill off the Big Kernel Lock (BKL). This is a stayover from the early days of Linux support for SMP (support for multi-processing) in which the in-kernel locking was very coarse and under the control of a single giant ‘Big’ kernel lock. The BKL continues to exist on some level even today – previous efforts to kill it having been thwarted – and it increasingly harms larger system scalability. Jan Blunk continues his excellent work to remove the BKL from various parts of the Linux VFS (virtual file system) by pushing such use down into individual file systems, where it can then be removed slowly. He even has patches to remove the BKL from ext2 file systems entirely when used in combination with his larger overhaul.
Processors
Last month also saw two interesting discussions surrounding Intel and Intel-compatible processors. First up was a discussion of optimal compilation flags for the AMD Geode processor (as used in the OLPC $100 laptop project) which traditionally was thought of as an i586-class processor. It turns out that it is possible to build a more efficient i686-compatible kernel with only a couple of tweaks, which may come in handy for distributions such as Fedora that have continued to build i586 compatible kernels until recently. On another CPU-related note, we heard from an engineer at Intel who tells us that the common wisdom that kernels should be optimised for space (cache usage, essentially) is no longer true with modern processors and that one can improve performance by as much as 8% by using the GCC -O2 performance optimisation flags and allowing the CPU to deal with cache pre-fetching.
Workflow and process
A number of interesting discussions took place last month surrounding various aspects of kernel workflow and development process. Ingo Molnar raised the issue of the stable kernel tree (a separate release maintained by Greg Kroah-Hartman and a small team of volunteers that provides updates to past – but still recent – kernel releases) and in particular how he should tag his patches as being required for the stable tree, such that they can be processed automatically. He also raised the issue of developers breaking up strings across lines and causing various grepping tools to break. A number of people suggested the true fix is to improve tools such that they can handle line-broken strings when searching.
Infrared control
There is some talk about finally integrating the legacy LIRC (Linux Infrared Remote Control) project into the mainstream kernel. This has traditionally provided external drivers that support homebrew IR receivers and other gadgets. A growing number of kernel developers are considering integrating this support by way of the kernel input subsystem, over objections from others that such devices can’t all be treated alike.
Last month even saw a brief discussion on licensing as Rusty Russell (author of the in-kernel module infrastructure) asked Ksplice author Tim Abbott to relicense his binary search support library code under GPLv3 so that he could pull the code into Samba (the file server project) rather than re-implement it. This, Rusty says, is why he always licenses his own code under GPLv2+ (ie allowing for future versions of the licence to automatically be covered).
Exciting though it is to see so many great advances in kernel development, one issue that repeatedly comes up (and won’t go away any time soon) is that of performance. Recent kernels have tended to perform a little worse in various benchmarks when comparing them with older 2.6 series releases. The delta isn’t all that huge (5-10% at most), but it is part of a trend that has a few people worried for the longer term. As Nick Piggin put it, “Unfortunately, our biggest competitors are our previous kernels.” That may be true, but it is also true that there is now growing interest in properly nailing performance regressions.
Finally though, spare a thought for a kernel developer named Dan Carpenter who is currently travelling across Africa and struggling to keep up with kernel development on expensive and infrequent bandwidth. Dan asked for help in cloning a fresh git tree using a protocol such as rsync that supports partial transfers, since he can only purchase 200MB of bandwidth at a time and this is not enough to fetch a complete git development tree. That’s all folks. Don’t forget to visit www.kernelpodcast.org (which had its 100,000th download this month) for daily updates on kernel development.
Jon Masters
