Linux-7.4-Patch öffnet Dateien im Test 39% schneller

Ein kleiner Patch für den Linux-Kernel, vorgesehen für Version 7.4, hat den Durchsatz beim Öffnen von Dateien im Benchmark seines Autors um 39% erhöht. Mateusz Guzik schickte die Änderung am 3. August 2026 an die Mailingliste linux-fsdevel, nach mehr als zwei Jahren Überarbeitung. Das ist bedeutsam, weil das Öffnen von Dateien zu dem gehört, was ein ausgelasteter Server am häufigsten tut, und diese Beschleunigung nichts kostet.

Der Patch trägt den Titel "fs: avoid spurious dentry ref/unref cycle on open". Er berührt das virtuelle Dateisystem, also die Kernel-Schicht über den einzelnen Dateisystemen, die Anfragen wie open und read bearbeitet.

Was der Patch ändert

Ein Dentry ist der zwischengespeicherte Eintrag des Kernels für ein Verzeichniselement. Er verbindet einen Namen in einem Pfad mit der Datei, auf die dieser Name zeigt. Der Kernel zählt, wie viele seiner Teile jeden Dentry gerade benutzen, damit er weiß, wann der Eintrag freigegeben werden darf. Diese Zählung ist ein Referenzzähler.

Guziks Commit-Nachricht beschreibt die Verschwendung klar. Beim Öffnen einer Datei wird in __legitimize_path() eine Referenz auf den letzten Dentry genommen. Danach nimmt do_dentry_open() eine zweite. Zuletzt gibt terminate_walk() die erste wieder frei.

Zwei dieser drei Schritte bewirken nichts. Der Patch lässt do_dentry_open() die Referenz übernehmen, die der Kernel ohnehin schon hält, statt eine neue zu nehmen und die alte freizugeben.

Die Änderung ist klein. Der Diff in Version 5 fügt 43 Zeilen hinzu und entfernt 4, verteilt auf drei Dateien: fs/internal.h, fs/namei.c und fs/open.c. Guzik beschreibt sie als einfachere Alternative zu einem aufwendigeren Patch-Satz von Al Viro, einem langjährigen Betreuer dieses Codes.

Referenzzählung wirkt für sich genommen billig. Billig ist sie nicht, wenn viele CPU-Kerne gleichzeitig denselben Zähler anfassen. Jede Änderung muss für alle anderen Kerne sichtbar werden, und diese stehen dadurch hintereinander Schlange.

Der Benchmark hinter den 39%

Die Zahl stammt aus will-it-scale, einer Testsammlung, die misst, wie sich Kernel-Operationen bei steigender Kernzahl halten. Guzik nutzte den Fall openro3.c, der dieselbe Datei in einer Schleife schreibgeschützt öffnet und schließt.

Auf einer virtuellen Maschine mit 20 Kernen ergab sich folgendes Bild.

Messung	Operationen pro Sekunde
Vor dem Patch	4.043.375
Nach dem Patch	5.629.378

Das ergibt die 39%. Phoronix berichtete am 19. September 2026 über den Patch und hält fest, dass er im Zweig vfs-7.4.lookup des VFS-Git-Baums für das Merge-Fenster von Linux 7.4 bereitliegt.

Was das für Entwickler bedeutet

Lesen Sie den Benchmark als das, was er ist. Im Fall openro3 öffnet jeder Kern dieselbe gemeinsame Datei schreibgeschützt in einer engen Schleife. Das maximiert genau die Konkurrenz um den Zähler, den dieser Patch nicht mehr anfasst. Deshalb fällt der Gewinn so groß aus. Er ist eine Obergrenze, keine Vorhersage für Ihre Arbeitslast.

Ihr eigener Gewinn hängt davon ab, wie viel Zeit Sie mit dem Öffnen von Dateien verbringen und wie viele Kerne das gleichzeitig tun. Drei Arbeitslasten liegen dem Benchmark am nächsten. Build-Systeme statten und öffnen Tausende von Headern. Webserver öffnen für jede Anfrage dieselben statischen Dateien. Werkzeuge für Container-Images und Pakete durchlaufen große Verzeichnisbäume. Einzelfädige Skripte auf einem Laptop werden kaum etwas merken.

Sie können Ihre eigene Betroffenheit messen, bevor der Kernel erscheint. Zählen Sie die Systemaufrufe open und openat in einem repräsentativen Lauf mit strace -c oder einem perf-Profil und setzen Sie das ins Verhältnis zur Gesamtlaufzeit. Wenn Öffnen in Ihrem Profil eine Randgröße ist, ist dieser Patch nicht Ihr Engpass, was auch immer die Überschrift sagt.

Planen Sie noch nicht mit einem Datum. Der Patch liegt in einem Teilsystem-Zweig. Er ist also von dessen Betreuer angenommen, aber noch nicht in den Hauptkernel übernommen. Phoronix berichtet von der Hoffnung, noch vor Ende 2026 in stabile Kernel zu gelangen. Ein Merge-Fenster kann das verschieben, und danach muss der Code über einen Distributionskernel zu Ihnen gelangen, was meist Monate hinzufügt.

Die allgemeinere Lehre ist die nützlichere. Dies ist eine Änderung von 43 Zeilen an einem Pfad, der seit Jahrzehnten milliardenfach am Tag durchlaufen wird, und er enthielt immer noch zwei überflüssige atomare Operationen. Heiße Pfade in reifem Code lohnen das erneute Lesen. Auch die Reihe kleiner Gewinne im Kernel geht weiter: im selben 7.4-Zyklus haben kbuild-Patches die Bauzeiten des Kernels verkürzt.