Kernel Log: Coming in 3.4 (Part 1) - Infrastructure

by Thorsten Leemhuis

The x32 ABI promises to make the advantages of x86-64 CPUs accessible while avoiding the overhead that comes with 64-bit code. Version 3.4 of the kernel will improve the power-saving capabilities of Xen. The new Yama module prevents processes from examining the memory of other processes.

Last weekend, Linus Torvalds published the fifth release candidate for Linux 3.4; one to three further RCs will likely follow before the final release of this kernel version, which is expected to arrive in the second half of May.

As usual, the kernel developers integrated all of the major new features for this version at the beginning of the development cycle. The Kernel Log can, therefore, already provide a comprehensive overview of the most important new features of Linux 3.4 – the kernel developers very rarely add, or revert, any major changes during the current stabilising phase.

As usual, the Kernel Log presents this overview in a series of articles that will successively cover the various kernel areas. The first article below describes the most important new features for the kernel's architecture code and basic infrastructure; subsequent articles will discuss the kernel's graphics drivers, filesystems, storage support and other hardware drivers.

Hybrid operation

From Linux 3.4, kernels that are compiled for x86-64/x64 processors can offer an "x32" ABI (Application Binary Interface) to programs (1 and others). Programs compiled for this ABI can access the 64-bit registers and data paths of 64-bit processors, but they only use 32-bit pointers – which are sufficient for many typical tasks and use less memory than 64-bit pointers.

Broadly speaking, this allows programs which are compiled for the x32 ABI to avoid the overhead that comes with full 64-bit operation while enabling them to benefit from some of the major advantages of 64-bit x86 processors. The latter is not possible when 32-bit x86 programs (x86-32/ix86) are executed on x86-64 distributions, a capability Linux has offered since the early days of its 64-bit x86 support.

The development of this concept has mainly been driven by Intel developers. The new ABI appears to be intended predominantly for the embedded and mobile markets: in the medium term, smartphones, tablets and similar devices with x86 processors will often have 4GB or more memory, which a 32-bit kernel can only address by using some trickery; however, most of the programs that are used on such devices are unlikely to require more than 4GB of memory, or they will gain enough from using 64-bit pointers elsewhere to compensate for the increased memory consumption of full 64-bit operation. What's more, the processors used in this environment tend to be slower, which means that the advantages gained by using 32-bit pointers instead of 64-bit pointers are more noticeable. In typical x86 processors for notebooks, desktops or servers, the overhead caused by full 64-bit operation is often rather small; therefore, the x86-64 distributions used on such systems will probably continue to compile the majority of their software as 64-bit programs for the native x86-64 ABI.

Further background information can be found on the x32 project's home page and in an article about the new ABI on LWN.net.

Virtualisation

Changes to the Xen code (1, 2, and others) include a modification that enables a Linux 3.4 operating as a Dom0 kernel to send some information on the processor's clock speed and sleep states to the Xen hypervisor, once the kernel has interpreted the BIOS's ACPI tables; the hypervisor can use this information to adjust the processor speed (P-states) or send the CPU into a short-term sleep state (C-states). This reduces power consumption, which can significantly prolong the battery life of some notebooks.

Because of the kernel's interpretation, the Xen hypervisor continues to be functional without a full ACPI interpreter. The Dom0 kernel itself can't handle clock speed adjustments or sleep states because the hypervisor has full control of the system and is, therefore, the only component to have an overview of the total system load; continuously coordinating the Dom0 kernel and the hypervisor at run-time would probably be too time-consuming. Xen requires similar kinds of trickery – in KVM, this is unnecessary because the Linux kernel is the hypervisor.

In 3.4, PCI 2.3 devices that share an interrupt line with other PCI devices on the host can be passed to KVM guests. The SCSI subsystem now includes the virtio-scsi driver which, together with the identically named support in Qemu, is suitable for providing a device emulation that controls the data traffic between host and guest without much overhead. According to its developer, the driver is more flexible, offers better scalability and is easier to use than virtio-blk – a driver which, according to the developer, offers a similar functionality but lacks features for certain use cases.

Next: Renovation work

1 2 3 4 next »

Print Version | Permalink: http://h-online.com/-1561840