This article is more than 1 year old

Linux kernel 3.9 lands

Power management, new processors, SSD caching and more

Linus Torvalds has unleashed version 3.9 of the Linux kernel.

Key features in the release include caching for SSD storage, new processor architectures, power management improvements targeting tablets and phones, Chromebook support, and a nod towards Android.

The caching change, present as the dm-cache target and currently described as experimental, lets one drive act as cache for another, so an SSD could be used as the cache device for a hard drive. The aim is to speed up data writes by using the faster SSD to take the writes and transfer them at leisure to the spinning rust. In the other direction, of course, frequently-used data can be cached from the hard drive to the SSD to speed up access.

In power management, a suspend-freeze mode now exists between “suspend to RAM” and normal idle states in power usage. The kernel can send hardware into its deepest available sleep state without powering down. This, according to H-Online, targets the smartphone/tablet market rather than PCs or notebooks.

Also on the power front, and more relevant to the PC / notebook, the libata drivers now support ZPODD – zero power optical drives, that are able to shut down completely when the drive is empty. Support for Intel's PowerClamp Linux driver (released last November) is also added in the new kernel.

The new kernel is now ported to the Synopsis ARC700 and Imagination Meta ATP and HTP processor cores – an embedded Linux play, since the first is mostly found in the digital media player and set-top-box market, and the Imagination devices turn in in digital radios.

Android development support arrives via the Goldfish virtualised development environment, so that developers can run up an Android instance easily on a standard kernel. Chromebook support is designed to cover all current devices in the Chrome laptop ecosystem.

An interesting but incomplete enhancement is a socket option called SO_REUSEPORT. This targets applications such as a Web server with multiple threads, all trying to bind to Port 80. As author David Miller writes, it's an alternative to having a single listener thread passing around the connections, on the one hand, or using a single listener socket to accept traffic from multiple threads.

“In case #1 the listener thread can easily become the bottleneck with high connection turn-over rate. In case #2, the proportion of connections accepted per thread tends to be uneven under high connection load (assuming simple event loop: while (1) { accept(); process() }, wakeup does not promote fairness among the sockets,” he says on the commit note.

There's lots more, with a fairly detailed run-down at The H here. ®

More about

TIP US OFF

Send us news


Other stories you might like