Ein Kernel-Speicherleck machte Redox-Builds fünfmal langsamer
Victoria Shinder2 Min. LesezeitRedox OS - das unixartige Allzweck-Betriebssystem mit Mikrokernel, geschrieben in Rust - hat seinen August-Bericht am 31. August veröffentlicht, verfasst von Ribbon und Ron Williams, mit einer Entschuldigung für die Verspätung. Er lohnt auch einen Monat später, weil zwei der Punkte Messungen sind und keine Ankündigungen.
Der erste ist Redox Rings, eine Ringpuffer-API, über mehrere Monate von Ibuki Omatsu und Anhad Singh gebaut, mit Anleitung von 4lDO2 und Fehlerkorrekturen von Wildan Mubarok. Das Projekt beschreibt sie als Äquivalent zur io_uring-Syscall-API von Linux; sie trägt nun den NVMe-Treiber, RedoxFS und RAMFS. In einem Benchmark, der RedoxFS umgeht und synchrone Systemaufrufe gegen Ringpuffer bei NVMe-Lesen und -Schreiben stellt, beträgt die Verbesserung 14-15x.
Der zweite ist eine Fehlerjagd. Wildan Mubarok verfolgte über Monate eine allmähliche Verschlechterung der GCC-Kompilierleistung und fand ein Speicherleck im Kernel: das Kompilieren der os-test-Suite unter QEMU war von zwei auf zehn Stunden gewachsen, mit Speicherüberläufen unterwegs. Nach der Korrektur dauert derselbe Vorgang etwa dreißig Minuten - schneller als die zwei Stunden, von denen die Verschlechterung ausging.
Der Rest des Monats: verbesserte UEFI-Kompatibilität, wodurch ein MSI Modern 14 C7M bootet; Mehrkernunterstützung für AArch64/ARM64 von lbecher, wobei das Projekt ausdrücklich sagt, der Leistungseffekt sei noch nicht vermessen; erste NUMA-Speicherverwaltung von Aadarsh samt standardmäßiger Allokation auf dem lokalen Knoten und einer libredox-API für die Allokationspolitik, bisher nur unter QEMU erprobt; sowie Prozessprioritäten und Prioritätsfeinabstimmung von Akshit Gaur, was das RSoC-Scheduler-Projekt abschließt, samt eines letzten EEVDF-Artikels.
Was das bedeutet
Das Leck ist der lehrreichere der beiden Befunde, wegen seiner Erscheinungsform. Nichts fiel aus - ein Build wurde einfach langsamer, Monat für Monat, bis er das Fünffache kostete und in Speichergrenzen lief. Diese Form widersteht der Diagnose: jeder einzelne Lauf gelingt, der Trend wird nur sichtbar, wenn jemand Build-Zeiten über Monate aufschreibt, und die naheliegende Erklärung für einen langsameren Compiler ist der Compiler oder der Code. Es dauerte Monate, es dem Kernel zuzuordnen. Übertragbar ist: eine langsame Drift in einer Zahl, für die niemand zuständig ist, ist die am schwersten erkennbare Fehlerklasse - und die Korrektur lieferte hier einen Build, der schneller ist als die älteste Referenz, das Leck war also länger vorhanden und hat länger stillschweigend Kosten erzeugt, als die Verschlechterung auffiel.
Die Rings-Zahl braucht den Vorbehalt, den das Projekt selbst mitliefert: die 14-15x sind mit umgangenem RedoxFS gemessen, gelten also für den Syscall- und Treiberpfad, nicht für das, was eine Dateisystem-Last sieht. Man vergleiche es mit dem ARM64-Eintrag, wo der Bericht jede Verbesserung offenlässt, bis Tests vorliegen. Ein Monatsbericht, der zwischen "unter diesen Bedingungen gemessen", "implementiert, Wirkung unbekannt" und "nur in QEMU getestet, echte Hardware willkommen" unterscheidet, leistet mehr als ein Changelog - und das ist der Grund, ihn vier Wochen später noch zu lesen.