Linux User & Developer, one of the nation’s favourite Linux and Open Source publications, is now part of the award winning Imagine Publishing family. Readers can subscribe and save more than 30% and receive our exclusive money back guarantee – click here to find out more.
Don’t forget to follow us on Twitter or get your first digital copy of the magazine for iPhone and iPad free – just search for ‘Linux User’ on the app store!
The past month saw steady progress toward the final 2.6.34 kernel release, including the announcement of initial Release Candidate kernels 2.6.34-rc1 through 2.6.34-rc4. The latter had an interesting virtual memory bug that added a week of delay (I will cover that in a future issue), and of course there was already an incompatible release of the nouveau graphics driver that was covered in last month’s column. But such issues aside, the 2.6.34 kernel is otherwise shaping up to be a good release, including a number of new features of some note as well as fixes for various performance regressions that have affected some of the more recent comparative benchmarks against older releases.
Amongst the new features in 2.6.34 are the LogFS log-based flash file system that has been in the works for the past few years as a replacement for JFFS2/3 (or YAFFS2 even), and support for asynchronous suspend and resume of devices, which should considerably improve system suspend and resume times because it allows for different subsystems to suspend in parallel rather than sequentially. The inclusion of LogFS support will be of particular interest to many embedded developers, since it provides a very scalable journaled flash file system with built-in file versioning support of the kind needed to really support today’s large flash devices, while async suspend and resume will benefit laptop users and those working on lower power devices that need to frequently use suspend.
Regressions have continued to be of particular interest of late as several of the larger vendors gear up for new enterprise Linux releases. Many comparative studies on the LKML allude to developers eager to compare older distribution kernel versions with the latest and greatest upstream releases. A number of such benchmarks – such as one from desktop-focused Phoronix – have shown an overall good progression from 2.6.24 through 2.6.30 (770% improvement overall in the aforementioned Phoronix benchmark), but a much more noticeable regression in 2.6.33 with “PostSQL performance atop the ext3 file system [falling] off a cliff” in that release. In mitigation, Rafael J Wysocki continues to do an excellent job assisting in collecting information on such regressions and nagging the developers involved to post fixes for these bugs via email.
Beyond 2.6.34, current kernel development includes a merging of Intel e820 BIOS provided hardware table parsing support into the more generic LMB – logical memory block – code. This should eventually allow for one single implementation of processing vendor-supplied descriptions of the locations of various parts of physical system memory and devices, rather than the two implementations in common use today (e820 on Intel x86 systems, and LMB on POWER/PowerPC, SPARC and other systems). This work came about following a number of (at times heated) discussions about the need to have a common approach.
There is also more work going into Big Kernel Lock elimination (the formerly giant, coarse-grained locking mechanism from the early SMP days), nested use of VM within KVM, an ability to effectively disable the page cache so that virtualised guest machines don’t need to provide a second page cache in addition to that of their host (which saves memory), and good progress toward a generic union file system mounts option – allowing for overlays of parts of one file system (for example a read-only DVD) with another (for example a writable memory-based) file system. There were of course the usual rants, this month including one started by Ingo Molnar and concerning the relative merits of SELinux as compared with AppArmor or TOMOYO, with the former being compared to a heavy fire door that provides great protection but often needs to be propped open to avoid becoming an unwieldy obstruction for its varied users.