Linux_2_6_21 - Linux Kernel Newbies

Released unknow, 2007 ([http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.21-rc5 full SCM git log])

Short overview (for news sites, etc)

2.6.21 improves the virtualization features merged in 2.6.20 with VMI (http://lwn.net/Articles/175706), a paravirtualization interface that will be used by Vmware (and maybe -probably not- Xen) software. KVM does get initial paravirtualization along with live migration and host suspend/resume support (http://lwn.net/Articles/223839). 2.6.21 also gets a tickless idle loop mechanism called "Dynticks" (http://lwn.net/Articles/223185), a feature built in top of "clockevents" which unifies the timer handling and brings true high-resolution timers. Other features are: bigger kernel command-line, optional ZONE_DMA; support for the PA SEMI PWRficient CPU, for a Cell-based "celleb" architecture from Toshiba, better PS3 support: support for NFS IPv6, IPv4 <-> IPv6 IPSEC tunneling support, UFS2 write support, kprobes for PPC32, kexec and oprofile for ARM, public key encription for ecryptfs, Fcrypt and Camilla cipher algorithms, NAT port randomization, audit lockdown mode, many new drivers and many other small improvements.

Important things (AKA: ''the cool stuff'')

VMI (Virtual Machine Interface)

VMI is a virtualization feature built in top of the paravirt_ops paravirtualization implementation introduced in [http://kernelnewbies.org/Linux_2_6_20 2.6.20].

More details about VMI can be found in this LWN article: "[http://lwn.net/Articles/175706/ The VMI virtualization interface]"

KVM updates

KVM does evolve at a very fast pace, due to its clean design. This release (KVM-15) brings many new features:

Initial paravirtualization support, which has [http://lkml.org/lkml/2007/1/5/205 much faster] performance
Live migration (the guest continues running even while being migrated) support. It's possible to migrate a guest from a Intel CPU to an AMD CPU
Host Suspend/resume support
CPU hotplug support - a useful feature for data centers, where you can add/remove CPUs according to the load
A stable userspace interface

Recommended LWN article: [http://lwn.net/Articles/223839/ "KVM-15"]

[http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=102d8325a1d2f266d3d0a03fdde948544e72c12d (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=02e235bc8eebf8a6fef10d46479b3c18f3e9c4f2 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c21415e84334af679630f6450ceb8929a5234fad 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=774c47f1d78e373a6bd2964f4e278d1ce26c21cb 4], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59ae6c6b87711ceb2d1ea5f9e08bb13aee947a29 5)]

Dynticks and Clockevents

Recommended LWN article: [http://lwn.net/Articles/223185/ "Clockevents and dyntick"]

(This feature touches a lot of low-level x86 code, so regressions are possible. If you have problems with 2.6.1, please [http://bugzilla.kernel.org report it])

Clockevents is a building block of dynticks. A example of a clock devices is the device which makes timer interrupts. The handling of those devices was made in the architecture-specific code, so there wasn't an unified way of using those devices. The clockevents patch unifies the clockdevice handling so the kernel can use the timer capabilities of those devices in a unified manner. This also allows to implement true high-resolution timers.

Dynticks (aka: dynamic ticks) it's a configurable feature for x86 32bits (x86-64 and ARM support is already done but not ready for this release; PPC and MIPS support are in the works) that changes the heart of the mechanism that allow a system to implement multitasking. To know what dyntick does, first you should know some basics: Traditionally, multitasking is implemented thanks to a timer interrupt that is configured to fire N times in a second. Firing this interrupt causes a call to the operative system's process scheduler routines. Then, the scheduler decides what process should run next, the process that was running before the timer interrupt was fired, or another process. This is how true multitasking is implemented in all the general-purpose operative systems, it's also what stops processes from being able to monopolize the CPU time: The timer interrupt will be fired regardless of what the process is doing and the operative system will be able to stop it.

N (the number of times the timer interrupt is fired in each second, aka 'HZ') is a hardcoded compile-time architecture-dependent constant. For Linux 2.4 (and Windows), HZ=100 (the timer interrupt fires 100 times per second). 2.6 increased HZ to 1000, for several reasons: 100 was the HZ value that x86 had been using since forever, and it didn't really had a lot of sense in modern CPUs that runs much faster: Higher HZ means smaller process time slices, which improves the minimum latency and interactivity. The downside is higher timer overhead (negligible in modern hardware, although some server-oriented distros package kernels with HZ=100 because of minor performance gains) and high pitch noises in some systems due to low-quality, cheap capacitators

Anyway, the issue is that the timer is fired HZ times in every second - even if the system is doing nothing. Dynticks is a feature that stops the system from waking up HZ times per second. When the system is entering the idle loop it disables the periodic timer interrupt, and programs the timer to fire the next time a timer event is needed. This means your system will be 'disabled' while there's nothing to do (unless a interrupt happens - ej: a incoming packet through your network). For now, dynticks does just that. However, this infrastructure will allow to create a innovative power-saving feature: When dynticks is in "tickless" mode and the system is waiting for the timer interrupt, the power-saving feature of modern CPUs will be used. This can save a few W when the laptop is idle. Dynticks also adds some nice configurable debugging features: /proc/timer_list prints all the pending timers, allowing developers to check if their program is doing something wrong when it should be doing nothing, /proc/timer_stat, in the other hand, collects some timer statistics, allowing to detect the source of commonly-programmed timers.

ASoC

The [http://www.rpsys.net/openzaurus/patches/alsa/info.html ASoC (ALSA System on Chip) layer] has been added to the ALSA sound system. Its aim is to provide improved support for sound processors on embedded systems. The ASoC core is designed to allow reuse of codec drivers on other platforms, reuse of platform specific audio DMA and DAI drivers on different machines, easy I2S/PCM digital audio interface configuration between codec and SoC, and allow machines to add controls and operations to the audio subsystem. e.g. volume control for speaker amp.

To achieve all this, ASoC splits an embedded audio system into 3 components: 1. Codec driver: The codec driver is platform independent and contains audio controls, audio interface capabilities, codec dapm and codec IO functions 2. Platform driver: The platform driver contains the audio dma engine and audio interface drivers (e.g. I2S, AC97, PCM) for that platform. 3. Machine driver: The machine driver handles any machine specific controls and audio events. i.e. turning on an amp at start of playback.

It includes a dynamic power management subsystem, designed to allow portable and handheld Linux devices to use the minimum amount of power within the audio subsystem at all times. It is independent of other kernel PM and as such, can easily co-exist with the other PM systems. DAPM is also completely transparent to all user space applications as all power switching is done within the ASoC core. No code changes or recompiling are required for user space applications. DAPM makes power switching decisions based upon any audio stream (capture/playback) activity and audio mixer settings within the device.

A number of platform and codec drivers for ASoC have been merged as well.