The kernel column by Jon Masters #82
Jon Masters is a Linux kernel hacker who has been working on Linux for almost 14 years, since he first attended university at the age of 13. Jon lives in Cambridge, Massachusetts, and works for a large enterprise Linux vendor…
Jon Masters is a Linux kernel hacker who has been working on Linux for almost 14 years, since he first attended university at the age of 13. Jon lives in Cambridge, Massachusetts, and works for a large enterprise Linux vendor. He publishes a daily Linux kernel mailing list summary at kernelpodcast.org.
We recently saw the opening of the merge window for the 2.6.32 kernel series, as well as the annual Kernel Summit (KS) in Tokyo, Japan. The latter caused a little disruption as many developers took a few days out to sample the delights of Tokyo (and there are many) in between travel and summit attendance. This coincided with a somewhat unpleasant ext4 file system corruption problem in the ext4 journal recovery code that affected a few users and delayed 2.6.32-rc6. Nevertheless, Linux was able to push out a number of exciting 2.6.32 ‘RC’ (release candidate) kernels over the past month, following the closure of the 2.6.32 feature merge window.
2.6.32 appears to be another good release. There are the typical kinds of problems with some known regressions, bugs (such as the ext4 one mentioned previously) and a security issue (that I’ll come onto later). But overall things seem to be progressing nicely. One area that does warrant some real improvement, however, is in performance regressions. A number of folks have noted over the past month how recent kernels are becoming more bloated and producing performance metrics that don’t quite rival earlier releases. One attempt to address this has come in the form of the ongoing work on ‘perf’ (performance events – formerly performance counters) and in particular the new benchmarking capabilities that have been added in ‘perf bench’, which is shipped along with the kernel in the ‘tools’ subdirectory.
Of the features currently under development, there are several that I think you should know about. These include character devices for network devices, fast symbol resolution, and enhancements to KVM. While most of these are internal to the kernel, the upcoming changes to OOM (out-of-memory) behaviour will be of interest to anyone who runs a large Linux deployment and needs to understand how it will behave in the presence of a low-memory condition.