Linux 6.14: Bessere Performance, aber verschlafener Release-Termin
Der Kernel Linux 6.14 verspricht Performance-Steigerungen bei Windows-Apps unter Wine und beim direkten I/O. Er erschien durch Vergesslichkeit einen Tag später.
(Bild: Erstellt mit KI in Bing Designer durch heise online / dmk)
Der neue Linux-Kernel 6.14 erblickte am Montagabend unserer Zeit das Licht der Welt. Damit erschien der Kernel-Neuling einen Tag später als üblich. Zwar gab es auf den letzten Metern ein paar Patches, die für Knirschen in der Build-Maschinerie der Kernel-Entwickler sorgten. Der Kern der Verzögerung war aber rein menschlich: Linus Torvalds hatte schlicht vergessen, den Kernel freizugeben. Das gab der Linux-Vater in seiner Release-Meldung unumwunden zu.
Der Kernel-Frischling bringt unter der Haube einige innovative Ideen unter. Die Neuerungen stehen im Zeichen der Leistungssteigerung.
Mutex, Futex und Windows
Sollen mehrere Threads auf eine gemeinsame Ressource verändernd zugreifen, braucht es eine Steuerung für die nebenläufigen, konkurrierenden Gesellen. Um den gleichzeitigen Zugriff auf die Ressource durch mehrere Theads zu verhindern, kommt ein Mutex zum Einsatz. Dieser sperrt (lock) die Ressource, wenn ein Thread auf diese zugreift. Alle anderen Threads, die ebenfalls die Ressource anfordern, werden so lange blockiert, bis der ursprüngliche Thread die Sperre aufhebt.
Linux verfügt mit "Fast Userspace Mutex" (Futex) über einen effizienten und flexiblen Mechanismus zur Synchronisation von Threads. Er kombiniert hierzu geschickt beim Verwalten der Mutexe Userspace und Kernelspace. Statt den Kernel generell mit der Sorge um den Mutex zu betrauen, bleibt die Verwaltung des Mutex im Userspace. Zum Anfordern eines Mutex braucht es keine Kernel-Rechte. Das Delegieren in den Kernelspace samt teurem Kontextwechsel ist nur dann notwendig, wenn Threads zu "parken" (sleep) oder "aufzuwecken" (wake) sind. Nämlich dann, wenn der Mutex bereits gesperrt ist oder wieder frei wird.
Innerhalb von Linux funktioniert dieser Mechanismus hervorragend, schnell und effizient. Probleme kommen auf, wenn andere Welten einzubinden sind. Das ist beispielsweise beim Nachbau von Windows in der Kompatibilitätsschicht Wine der Fall. Die meisten Windows-Sperren lassen sich auf Futex abbilden. Der Locking-Bauchladen von Windows funktioniert intern anders, sodass einiges nicht ohne Scheuern und Wetzen sowie Kopfzerbrechen möglich ist.
Videos by heise
Problem Windows-Nachbau
Die Liste der Abbildungsschwierigkeiten ist lang. Schwer abzubilden ist beispielsweise das Anfordern mehrerer Sperren in einem Schritt. Auch die speziellen Sperren in Form von Events (Ereignisse) von Windows harmonieren nicht mit dem Futex-Konzept. Das Event ist eine Bedingungsvariable in Form eines booleschen Werts. Als Sperrwert hat das Event "falsch" (false). Die Threads warten, bis die Variable den Wert "wahr" (true) annimmt. Soweit wäre das auch mit Futex problemlos lösbar. Der Teufel steckt jedoch wie so oft im Detail.
Es gibt zwei Typen von Events. Sie können selbst rücksetzend (auto-reset) sein. Sowie ein Thread in der Warteschlange zum Zuge kommt, wechselt der Wert zurück auf false. Die anderen Threads sehen dieses Ereignis überhaupt nicht. Ist das Event nicht als "auto-reset" gekennzeichnet, setzt sich der Wert nicht zurück, sondern verharrt auf true. Der Wert muss explizit wieder auf false zum Sperren gesetzt werden. Das sehen alle wartenden Threads.
Um dem Herr zu werden, hat die Entwicklerin Elizabeth Figura eine Reihe von Patches beigesteuert. Linux 6.14 bringt einen neuen Treiber zur NT-Synchronisation mit. Er findet sich als /dev/ntsync im virtuellen Dateisystem wieder. Alle Synchronisationsmechanismen von Windows sind darin ausgelagert, die mit Futex nicht mehr oder weniger eins zu eins realisiert werden können. Die Dokumentation zu ntsync findet sich bei docs.kernel.org.
