Seite 5: Modul-Exporte partitionieren und Echtzeitfähigkeiten

Inhaltsverzeichnis

Torvalds schraubt überraschend am Zufallszahlengenerator

Linus Torvalds, der dieser Tage nur noch selten eigenhändig größere oder signifikante Kernel-Änderungen für der Linux-Kernel entwickelt, hat ausnahmsweise selbst eine umfangreichere Änderung am Zufallszahlengenerator des Kernels vorgenommen. Damit generiert der Pseudo Random Number Generator (PRNG) bei Engpässen nun neue Zufallszahlen mithilfe von Entropie, die er selbst erzeugt, indem er Prozessorbefehle absetzt und deren Ausführungsdauer mit CPU-Cycle-Countern misst.

Diese Änderung geht ein in der Endphase der 5.3-Entwicklung viel diskutiertes Problem an: Nach einer Optimierung am Ext4-Code kam der Startvorgang bei einigen Anwendern ins Stocken, weil plötzlich nicht mehr genug Entropie erzeugt wurde und Userspace-Anwendungen dadurch endlos auf neue Zufallszahlen warteten. Der für den Generator zuständige Entwickler und Torvalds kamen zu der Zeit in längeren Diskussionen nicht zu einer adäquaten Problemlösung, woraufhin der Linux-Vater die Ext4-Optimierung wenige Tage vor der Fertigstellung von 5.3 überraschend entfernte.

Als im folgenden niemand eine Lösung vorantrieb, schritt Torvalds schließlich am Ende der Hauptentwicklungsphase von Linux 5.4 kurzerhand selbst zur Tat: Er setzte die von ihm vorgeschlagene Entropie-Erzeugung über Cpu-Cycle-Counter direkt im Hauptentwicklungszweig um und überging dabei die sonst übliche öffentliche Vorabbegutachtung vollkommen. Direkt danach pflegte er dann auch die Ext4-Optimierung wieder ein. Kurz darauf ließ er auf der Mailingliste durchblicken, durch sein direktes und weitgehend unabgesprochenes Vorgehen vielleicht andere Entwickler zu motivieren, einen noch besseren Ansatz zu entwickeln – was aber nicht passierte, daher bleibt jetzt vorerst alles, wie es ist. Weitere Details dazu finden sich im LWN.net-Artikel "Really fixing getrandom()".

Modul-Exporte partitionieren

Die neuen Symbol Namespaces könnten über kurz oder lang auch ein Problem für Entwickler externer Treiber werden – egal ob proprietär oder Open Source. Über die Symbol Namespaces können die Kernel-Programmierer nämlich die Verfügbarkeit der Symbole einschränken, über die Kernel-Module einzelne ihrer Funktionen exportieren können, damit Code anderer Kernel-Module auf diese zurückgreifen können.

Beispielhaft implementiert wurde solch ein Namespace bei den USB-Storage-Treiber: Code, der deren Funktionen nutzen will, muss sie daher jetzt über MODULE_IMPORT_NS(USB_STORAGE); explizit einbinden, sofern die neue Bauoption CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS denn beim jeweiligen Kernel-Image gesetzt ist. Prinziell kann man die Symbol Namespaces aber auch nutzen, um bestimmte Symbole nur zur internen Nutzung freizugeben, was zu einer Hürde für unabhängig gewartete Kernel-Module werden könnte.

Details zu diesem Thema finden sich in einigen Commit-Kommentaren (u. a. 1, 2, 3), der Dokumentation und dem LWN.net-Artikel "Kernel symbol namespacing".

Fortschritte beim Realtime-Support und Prozess-API

Nachdem bei Linux 5.3 klargestellt wurde, dass Linux bald von Haus aus Echtzeitfähigkeiten bieten soll, folgten bei Kernel 5.4 einige im PREEMPT-RT-Zweig vorangetriebene Umbauten und Erweiterungen, um diesem Ziel näher zu kommen (u. a. 1, 2, 3, 4, 5, 6). Eines der wichtigen Features, was zum Realtime-Support noch fehlt, ist eine neue Printk-Infrastruktur, die sicherstellt, dass beim Protokollieren von Kernel-Ereignissen keine langen Wartezeiten entstehen. Von den dafür nötigen Umbauten ist bislang aber nicht viel zu sehen, daher dürften sie frühestens bei Linux 5.6 folgen.

Das "Scheduler Utilization Clamping" lässt sich jetzt auch über Control Groups (Cgroups) steuern; über diese kurz Uclamp genannte und bei Linux 5.3 nachgerüstete Technik können Admins oder Entwickler einzelne Programme speziell auszeichnen, um deren Reaktionsfreude zu steigern oder die Leistungsaufnahme des Systems im Zaum zu halten.

Mit dem neuen P_PIDFD-Flags des Syscall waitid() können Prozess-Management-Programme jetzt auf Prozesse warten, um so automatisch über deren Ableben zu erfahren und dabei auch dessen Rückgabewert zu erhalten. Mit dieser und einigen zugehörigen Änderungen ist die Basis des neuen Pidfs-APIs jetzt komplett; Christian Brauner hat es im Verlauf der letzten zwei Jahre vorangetrieben, um das Prozess-Management und damit auch den Container-Betrieb robuster zu machen. Details hierzu liefern die LWN.net-Artikel "Completing the pidfd API" und "Adding the pidfd abstraction to the kernel". Letzterer fasst einen Vortrag zusammen, von dem sowohl Vortragsfolien als auch eine Videoaufzeichnung frei abrufbar sind:

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Reproduzierbar bauen und Performance-Verbesserungen für Android

Die Kernel-Dokumentation liefert jetzt Hinweise zum reproduzierbaren Bau ("Reproducible Build") von Linux. Bei so einem Bauprozess entsteht beim wiederholten Übersetzen stets ein bitgleiches Resultat, daher kann man damit untersuchen, ob ein vorliegender Kernel tatsächlich aus einem bestimmen Quellcode entstanden ist.

Einige Umbauten versprechen die Performance der Vsock-Infrastuktur deutlich zu verbessern, über die bei Virtualisierung der Host und sein Gast effizient kommunizieren können.

Android-Entwickler haben einige Änderungen beigesteuert, mit denen sie die Performance und den Start von Apps beschleunigen wollen. Dazu rüsten die Patches die madvise()-Flags MADV_COLD und MADV_PAGEOUT nach. Mit ihnen kann das Smartphone-Betriebssystem dem Kernel einige Hinweise auf Arbeitsspeicherbereiche von Programmen geben, die höchstwahrscheinlich in naher Zukunft ohnehin nicht benötigt werden, weil die Anwendung vielleicht gerade geschlossen wurde; dadurch kann der Kernel die Arbeitsspeicherinhalte bei Bedarf früher verwerfen und so Platz für wichtigere Dinge schaffen.

Längeres Hin und Her hat wohl ein Ende

Mit Linux 5.4 scheinen auch endgültig Streitereien um einen Patch zu Ende zu gehen, der die transparente Handhabung großer Speicherseiten (Transparent Hugepages/THP) zu optimieren versuchte. Er wurde bereits einmal aufgenommen und nach Beschwerden eines Entwicklers wieder entfernt, nach mehreren Monaten und allerlei Diskussionen aber jüngst bei Linux 5.3 erneut eingepflegt. Details hierzu erläutert LWN.net im Artikel "Dueling memory-management performance regressions". Der Kritiker meldete sich erneut zu Wort und fand schließlich zusammen mit den zuständigen Entwicklern und Linus Torvalds eine für alle zufriedenstellende Lösung – in dem Zug wurde der Patch dann aber ein zweites Mal hinausgeworfen, was zur leicht verwirrenden Commit-Überschrift 'Revert "Revert "Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask""'' führte.

Einige weitere Neuerungen rund um Infrastruktur des Kernels nennen die wichtigsten Merge-Commits der Bereiche ACPI, Compiler-Attributes, Dokumentation, EFI, Heterogeneous Memory Management (HMM), Kbuild, Kgdb, PCI, Perf, Power-Management, RCU, Prozess-Scheduler, Tracing und Vfio.