Linux Weather Forecast
Welcome to the Linux Weather Forecast
This page is an attempt to track ongoing developments in the Linux development community that have a good chance of appearing in a mainline kernel and/or major distributions sometime in the near future. Your "chief meteorologist" is Jonathan Corbet, Executive Editor at LWN.net. If you have suggestions on improving the forecast (and particularly if you have a project or patchset that you think should be tracked), please add your comments to the Discussion page. There's a blog that reports on the main changes to the forecast. You can view it directly or use a feed reader to subscribe to the blog feed. You can also subscribe directly to the changes feed for this page to see feed all forecast edits.
Current conditions: the 3.9 kernel was released on April 28, 2013. Some of the key features in this release include:
- Virtualization with KVM is now supported on ARM Cortex-A15 processors.
- Dynamic frequency selection suppport is being added to the wireless networking subsystem, allowing high-frequency networking to coexist safely with air traffic control radars.
- VMware's "VM Sockets" and "Virtual Machine Communication Interface" subsystems have been merged into the mainline kernel.
- User namespace support is now almost entirely complete now that all major filesystems except XFS have been updates.
- The SO_REUSEPORT networking option makes it easier to set up scalable, multi-process network servers.
- Intel's PowerClamp driver can control power consumption in data center settings through the forced injection of idle cycles.
- The new "dm-cache" device mapper target can use a solid-state device as a fast cache for slower storage devices. See the associated documentation file for details.
- The Btrfs filesystem has finally gained RAID5 and RAID6 support on an experimental basis.
Some 11,900 changesets were merged during the 69-day 3.9 development cycle. It is not the busiest kernel cycle ever, but it did set a record of another type: the 1,388 developers who contributed to this kernel are the most ever. See this article for more information on the 3.9 cycle and who the major contributors were.
Short-term forecast: the 3.10 kernel can be expected in early July. The headline features in this release will include:
- A long list of improvements to the "ftrace" tracing facility, including the ability to separate event streams into multiple tracing buffers.
- The memory pressure notification mechanism has been merged, giving user-space controllers the ability to react when memory gets tight.
- The kernel has gotten much closer to full dynamic tick support. This feature allows the kernel to suspend the periodic timer interrupt while a single task is running; it is mostly of interest (in its current form) to highly latency-sensitive high-performance computing and real-time applications.
- "Tail loss probing" in the networking stack will help speed recovery when packets are lost at the end of a network session.
- The XFS filesystem has gained support for metadata checksumming, making it far more resistant to data corruption at the storage layer.
- ARM multi-cluster power management has been merged. This feature will not change anybody's life yet, but it is an important component for proper support of ARM "big.LITTLE" systems.
- The bcache caching layer, which allows a solid-state device to serve as a high-speed cache for a larger, slower storage array, has been merged.
Nearly 12,000 changesets were pulled into the mainline during the 3.10 merge window. That is by far the busiest merge window ever, making it likely that 3.10 will end up being the busiest kernel development cycle ever as well.
As with the weather, there are no certainties about what may be merged into the Linux kernel going forward; every change is evaluated on both its merits and its long-term maintenance costs. Here are a few things on the horizon that are worth watching, though.
The Android kernel patches. These changes have been the subject of extensive discussions and have, thus far, not been accepted into the mainline kernel. At the 2011 Kernel Summit, though, it was decided that this code should probably go in. Longstanding tradition says that code which is actively shipped, supported, and used should eventually be merged, even if it has problems. Nothing is certain until it happens, but we will probably see some movement in this area, perhaps for the 3.3 release.
The Btrfs filesystem is heading into active use. Oracle has confirmed that it intends to use it as the default filesystem in its enterprise distribution. Remaining issues (as discussed at LinuxCon Europe) include a functional filesystem repair tool and the merging of RAID5/6 support.
Realtime preemption - the provision of deterministic response in the Linux kernel - has been developed out of tree since 2004. Current plans call for the merging of much of that code within the next few development cycles, leaving only the core realtime work out of the mainline. See the report from the October 22 realtime minisummit for more information.
x32 is a new binary interface standard for 64-bit architectures; it is intended to provide better performance for applications that do not actually need 64-bit address spaces. Since most applications have no such need, the benefits could be significant. There are some remaining issues to be worked out, but the bulk of the work is done and we should be able to expect x32 support to be merged sometime in 2012. Some more information can be found in this article.
Control groups are the mechanism by which the kernel gathers processes into hierarchical groups; it can then apply policies and resource usage limits to those groups. This feature has been somewhat controversial within the kernel community, but its use is growing and shows every sign of continuing to do so. Over the next year or so we can expect to see a lot of work in this area along two lines: (1) adding new controllers to apply policies to groups, and (2) improving the implementation of control groups and the controllers to make kernel developers happier. Some more information can be found in the 2011 Kernel Summit control groups discussion.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
By "core kernel," I mean code which affects the kernel as a whole and which isn't tightly associated with a single subsystem. The core of the Linux kernel is quite small, and it has also been surprisingly stable in recent times. The CPU scheduler has seen mostly incremental changes, and the core memory management code has seen few fundamental changes for years. On the other hand, there is still interest in a number of areas, including real time, asynchronous I/O, fast booting, and more.
Virtualization and containers are complimentary efforts which seek to allow different tasks to be isolated from each other on the same host system. In virtualization, the guest systems appear to be running on their own hardware; each guest system runs its own kernel. The container approach runs all guests under the same kernel in a way that isolates them from each other. Virtualization gives more complete isolation and allows guests to be running a different operating system than the host; containers, however, tend to be far more efficient.
Filesystems, of course, are a crucial part of any operating system; they are the code which maintains our persistent data. Reliability is of especially high importance in filesystems, since any mistakes can lead to lost data or (even worse) subtly corrupted data which is not discovered for a long time. But filesystems are also a performance-critical part of the system; a poorly-written filesystem will result in substandard performance for almost any kind of workload.
Security is a difficult and complicated problem, which must be addressed at several levels. The technologies discussed in this page are mainly concerned with mandatory access control - the hardening of the system so that no component of that system may go beyond its permitted capabilities. The largest value of MAC schemes is often seen when a system component is compromised as a result of an internal bug. If the MAC system has been set up properly, the compromised application should not enable the attacker to take control of the system as a whole.