18 March 2009, 08:33

Kernel Log: What's new in 2.6.29 - Part 8: Faster start-up and other behind the scenes changes

Following the eighth pre-release version of 2.6.29, development of the next major kernel revision looks to have hit the home straight. A glance at the changed files and code makes it clear how hard the kernel hackers have been working on 2.6.29, with more new lines of code added over the current development cycle than ever before.

The bulk of the extra code is, as usual, made up of drivers and the sub-systems that surround them. The number of changes which improve behind-the-scenes aspects of the kernel infrastructure is, however, far from small and these are the subject of this Kernel Log, which concludes the "What's coming in 2.6.29" series â indeed it can't be long before Linus Torvalds releases Linux version 2.6.29.

Fastboot

Following on from his "Fastboot" enhancements introduced in 2.6.28, which accelerate the kernel initialisation phase, and by extension, system start-up, Arjen van de Ven has generated further improvements in this area for 2.6.29. These now allow the kernel to initialise some mutually-independent subsystems asynchronously. This allows for the initialisation of one subsystem while code from another subsystem is still, for example, waiting for a response from the hardware it deals with. This kind of wait is especially common when initialising the Libata and SCSI subsystems, which at some points wait for tenths of a second or longer for drives to respond, when querying and setting up media.

This trick allows the boot phase between starting the kernel and transferring to userspace (/sbin/init) to become measurably and tangibly faster â the magnitude of the benefit is, though, strongly system-dependent. Due to some problems, however, parallel initialisation will be largely deactivated in 2.6.29 unless the fastboot code is explicitly activated using the "fastboot" kernel parameter. Van de Ven is planning to take a second shot at the problem in 2.6.30 to allow more users to benefit from these changes. More details on how fastboot works can be found in an article on LWN.net.

Virtualisation and security

KVM developers have once again been busy, introducing around 150Â patches, which include enhancements to NMI, MSI and Kdump support and allow faster access to the MMU. Changes to the IOMMU subsystem improve support for assigning PCI/PCIe devices to guest systems. A number of patches also improve support for container virtualisation. The new Xenfs should improve the interaction between userspace and Xen.

The task credentials patches, which restructure the way the kernel deals with process-specific information (user and group ID, privileges, etc.), have been adopted in this kernel version (LWN.net article, kernel documentation). The LSM (Linux Security Modules) now offer hooks for security frameworks such as AppArmor and Tomoyo, which may use file names to recognise programs â SELinux and Smack, by contrast, rely on extended attributes. From 2.6.29, the kernel's cryptographic code will be able to deal with shash.

Behind the scenes

The Cpumask changes, driven primarily by Rusty Russell, now allow distributors to compile their kernels with support for up to 4096Â CPU cores without incurring major performance penalties on dual or quad core systems. Russell gives a rough overview of the background to the changes and how the code works on his blog.

The TreeÂ RCUÂ patches should allow the kernel to better scale to systems with "a few hundred processors" (e.g. 1). Interested users can find a detailed explanation of how the new code works in an LWN.net article written by a patch author working for IBM.

There are also a whole heap of changes relating to the ftrace tracking infrastructure. The kernel hackers have also included patches to allow the poll() function to sleep and introduced functions which can be used to protect exclusive access to I/O Memory. (LWN.net article). The latter allows drivers to protect I/O memory space used for communicating with hardware from unwanted write access by userspace programs, which can, in the worst case, make the hardware unusable â as occurred with the "e1000e problem", where an internal kernel error during 2.6.27 development disabled some Intel network cards.

The kernel can no longer be correctly compiled using GCC versions 3.0, 3.1, 4.1.0 and 4.1.1.

Yet more changes

In addition to the new features described in this article, the kernel development team has also included a large number of additional patches in 2.6.29 â the kernel hackers have, for example, combined the directories containing the code for supporting SPARC and SPARC64 and have extended the ARM code to add support for the i.MX31. Details of these and many less major, but in no way insignificant, changes can be found in the list below. The individual entries link to the relevant commit in the Linux source code control system, where further information on the change and the relevant patch can be found.

Fastboot

Tracing

Crypto/Security

Virtualisation

Architecture

Generic

Generic â Cpumasks

ARM

Blackfin

MIPS

Power

S390

SPARC

x86

Miscellaneous

Miscellaneous

Further background and information about developments in the Linux kernel and its environment can also be found in previous issues of the kernel log at The H Open Source: