Linux 6.14: Better performance, but delayed release date

Contents

The new Linux kernel 6.14 saw the light of day on Monday evening our time. This means that the new kernel was released a day later than usual. There were a few patches over the last few meters that caused the kernel developers' build machinery to grind to a halt. However, the core of the delay was purely human: Linus Torvalds had simply forgotten to release the kernel. The Linux father openly admitted this in his release message.

The kernel freshman has some innovative ideas under the hood. The new features are aimed at improving performance.

Mutex, Futex and Windows

If several threads are to access and modify a shared resource, a control system is required for the concurrent, competing threads. A mutex is used to prevent simultaneous access to the resource by several threads. This locks the resource when a thread accesses it. All other threads that also request the resource are blocked until the original thread releases the lock.

With "Fast Userspace Mutex" (Futex), Linux has an efficient and flexible mechanism for synchronizing threads. It cleverly combines userspace and kernel space when managing the mutexes. Instead of generally entrusting the kernel with the care of the mutex, the management of the mutex remains in userspace. No kernel rights are required to request a mutex. Delegation to the kernel space, including an expensive context switch, is only necessary if threads are to be "parked" (sleep) or "woken up" (wake). Namely when the mutex is already locked or becomes free again.

Within Linux, this mechanism works excellently, quickly and efficiently. Problems arise when other worlds need to be integrated. This is the case, for example, when replicating Windows in the Wine compatibility layer. Most Windows locks can be mapped to Futex. The Windows locking belly store works differently internally, so some things are not possible without scrubbing and sharpening and headaches.

Windows replica problem

The list of mapping difficulties is long. For example, requesting several locks in one step is difficult to map. The special locks in the form of Windows events also do not harmonize with the Futex concept. The event is a condition variable in the form of a Boolean value. The event has the lock value "false". The threads wait until the variable assumes the value "true". So far, this could also be easily solved with Futex. However, as is so often the case, the devil is in the detail.

There are two types of events. They can be self-resetting (auto-reset). As soon as a thread in the queue comes into play, the value changes back to false. The other threads do not see this event at all. If the event is not marked as "auto-reset", the value is not reset but remains at true. The value must be explicitly set back to false to lock. All waiting threads see this.

To deal with this, developer Elizabeth Figura has contributed a series of patches. Linux 6.14 comes with a new driver for NT synchronization. It can be found as /dev/ntsync in the virtual file system. All Windows synchronization mechanisms that cannot be implemented more or less one-to-one with Futex are stored in it. The documentation for ntsync can be found at docs.kernel.org.

Performance boost for gamers

The whole effort has a concrete goal. Windows programs based on Wine can be massively slowed down. For example, if an auto-reset event hangs on several simultaneously requested resources, things get hairy.

In Windows, several simultaneously requested resources can be blocked in one go and thus atomically. The composition of the resources can vary at runtime. A futex cannot map this adequately. Instead, a waiting thread would receive individual resources from the group when they become free. If not all resources are available, the waiting thread goes back to sleep. If the next resource from the bundle becomes free, this does not necessarily mean that it goes to the same thread. Depending on the implementation, the consequences can range from jerky applications to the Windows app freezing.

The new approach is intended to avoid this and promises a gain in speed. Graphics-heavy apps and Windows games in particular will benefit. As not all Windows applications are equally affected by this special type of synchronization, the forecast for the increase in speed lies within a broad range. For the frame rate of games, the increase is expected to be between 50 and 150 percent.

Reconciling contradictions

Until now, there have been two main types of file I/O in Linux. Either buffered or direct. The standard behavior is buffered I/O, which reads and writes data via the page cache. The advantage is fast access during repeated reads. The data is stored in the page cache and does not have to be fetched again from the mass memory at great expense. Buffered I/O comes at the cost of the problem with all caches.

The page cache can be inconsistent, i.e. no longer match the content on the storage medium. This is the case when other parts of the system change the same data but bypass the cache. Good old Direct Memory Access (DMA) and Direct I/O are prominent examples that can get in the way of Buffered I/O.

Direct I/O bypasses the page cache completely and always accesses the mass memory directly. The data via Direct I/O always reflects the current status on the storage medium. The disadvantage is the sometimes slower access to the data. This is particularly the case with several small accesses, as no data is read or written in advance over a block size. In contrast, buffered I/O can write and read data with the optimum block size. The cache makes it possible.

Buffered unbuffered

Linux 6.14 combines the two opposing approaches in a middle way. At first, the new "Uncached Buffered I/O" sounds contradictory: non-buffered, but nevertheless buffered accesses. After all, a cache is just a buffer.

The trick is to use the page cache in the same way as with buffered I/O. However, the cached data is not reused. The pages used are discarded and not marked as "clean" for reuse. Each access fetches the data anew from the storage device. In short: "Act like Buffered I/O, but pretend the page cache is empty."

This makes Uncached Buffered I/O more flexible and efficient for small accesses than Direct I/O. The normal block size on access allows optimized reading from the storage device. There is no need to invalidate caches, as would otherwise be necessary when merging the two approaches. The approach is lean and easy to implement in the kernel. Applications that "cache" themselves or change data multiple times benefit from better performance.

Buffered I/O is the best choice for normal programs. Direct I/O is the domain of databases and high-performance computing (HPC), which want to manage and cache data themselves and sit close to the hardware. The new Uncached Buffered I/O closes the gap for high-performance applications that want efficient buffered reads but rely on the consistency of the data.

The hard core

Processes running on the GPU are reluctant to be aborted. After all, the computing-intensive tasks should not have to be restarted. The new kernel declares war on forced ejection via cgroups. Linux now splits both GPU resources and CPU memory allocated by drivers into cgroups. This allows parallel execution of tasks without influencing each other.

With the predecessor 6.13, Linux introduced the "Lazy Preempt". In preemptive multitasking, it allows context switches to be postponed so that processes or threads are not interrupted unnecessarily. In this way, processing steps can be completed in one go if possible. This "lazy preempt" was only available in Linux 6.13 on computers with CPUs of type x86/x86_64 and RISC-V. Now the kernel newcomer is following suit for the next architecture. With Linux 6.14, the "Lazy Preempt" is also available for systems with PowerPC.

File systems and Copilot

The btrfs file system introduces three new strategies for read balancing in RAID1 (mirroring). "Rotation" keeps all devices of the mirror active and is the default setting. "Latency" intelligently tackles error-prone and unstable block layers. Finally, "devid" allows manual control. Depending on the application scenario, the appropriate strategy should help to better distribute read accesses across the devices in RAID1.

XFS enhances its real-time device. This special mode enables consistent, predictable latencies for file system operations. The new Linux kernel adds "reverse mapping". It allows blocks on the storage device to be mapped to the file from which the storage blocks are used. Normally, the associated blocks can only be identified from the file. Another new feature is "reflink". This allows files in XFS to share memory blocks. This avoids redundancy and saves storage space.

Microsoft has added a new key to PC keyboards. The Copilot key is used to access the AI assistant of the software giant from Redmond. Until now, Linux ignored this key. Now Linux also recognizes when this key is pressed. However, this does not create a permanent link to the Copilot assistant.

Summarized

With just over 11,000 changesets with new functionality, Linux 6.14 lags modestly behind a long line of its ancestors. Only Linux kernels of versions 4.x were smaller in this respect. Despite this "meager" quantity, the new version brings a lot of quality. The speed increases in Windows games are remarkable. The ingenious trick of uncached buffered I/O closes a gap between the otherwise opposing I/O strategies. This alone makes the next incarnation of the kernel an innovation boost.

The Linux kernel 6.14 is available for download as usual at kernel.org. All new features and changes are summarized in the changelog. A structured overview of the changes compared to the predecessor 6.13 can also be found in the git repository.

(wpl)