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.