14. Oktober 2026LWN.net · KernelKuratiert

Torvalds' erste Patch-Serie mit KI-Hilfe: 23-mal schneller, trotzdem mit Fehler

Zusammenfassung

Linus Torvalds hat seine erste Patch-Serie veröffentlicht, die mit Hilfe eines KI-Programmierassistenten entstanden ist: Zehn Patches sollen ein seit Jahren bekanntes Skalierungsproblem beim Lesen aus dem Page Cache lösen. In einem künstlichen Test mit 64 Threads steigen die Lesevorgänge pro Sekunde um das 23-Fache, was laut Torvalds im echten Betrieb deutlich weniger sein wird. Schon wenige Stunden nach der Veröffentlichung fand der Kernel-Entwickler Kiryl Shutsemau im Review eine Race Condition und lieferte die Korrektur gleich mit.

Worum es geht

Wenn viele Threads gleichzeitig dieselbe Datei lesen, erhöht und senkt der Kernel bei jedem read() den Referenzzähler der betroffenen Speicherseite. Diese Schreibzugriffe auf eine gemeinsame Cache-Zeile bremsen große Maschinen aus: Im Test von Torvalds bleibt der Durchsatz bei 13,3 Millionen Lesevorgängen pro Sekunde stehen, jeder Lesevorgang kostet rund 20.000 Prozessortakte. Matthew Wilcox hatte 2024 gemeldet, dass reale Anwendungen an diese Grenze stoßen.

Mehrere Anläufe scheiterten seitdem: ein früher Entwurf von Torvalds, den Torvalds eineinhalb Jahre lokal nutzte, bis andere zeigten, wie fehlerhaft er war, eine verbesserte Fassung von Kiryl Shutsemau vom Oktober 2025 und ein ganz anderer Ansatz von Ilya Gladyshev, inzwischen in Version 6 und mit bekannten offenen Problemen.

Der Lösungsansatz

Die neue Serie dreht die Logik um: Eine Seite, die den Page Cache verlässt, geht erst nach einer RCU-Wartezeit (Grace Period) an den Speicherverwalter zurück. Solange ein Leser im RCU-Abschnitt ist, bleiben die Daten also gültig, und der Kernel kann ohne Referenzzähler direkt in den Puffer des Programms kopieren. Statt ungültige Zustände nachträglich zu erkennen, verhindert die Serie, dass sie überhaupt entstehen.

Das Ergebnis auf einem Threadripper mit 64 Threads: 304 statt 13,3 Millionen Lesevorgänge pro Sekunde und rund 735 statt 20.000 Takte pro Lesevorgang. Auf einem Laptop mit acht Threads stieg der Durchsatz von etwa 10 auf 30 bis 33 Millionen. Torvalds betont selbst, dass der Test künstlich ist: dieselben wenigen Bytes, immer wieder von allen Kernen gelesen.

Wie die KI eingesetzt wurde

Die Arbeit entstand für den Maintainers Summit 2026, auf dem der Einsatz von Sprachmodellen in der Kernel-Entwicklung ein großes Thema war. Torvalds wollte zeigen, dass sich ein echtes, ungelöstes Problem damit lösen lässt, und hielt eine einfachere Aufräumarbeit an der assoc-array-Bibliothek als Rückfalloption bereit.

In der Beschreibung des ersten Entwicklungszweigs steht, dass Code, Testprogramme, die Durchsicht hinter der Liste offener Probleme und der erste Textentwurf mit dem Programmierassistenten Claude Code unter Torvalds' Anleitung entstanden sind, die Messungen liefen auf Torvalds' eigenem Rechner. Jeder der zehn Commits trägt die Zeile „Assisted-by: LLM“, zwei davon stammen von Kiryl Shutsemau. Die Commit-Texte seien ausführlicher geraten, als Torvalds sie selbst geschrieben hätte, aber vielleicht sei das besser so.

Was das Review zeigt

Rund vier Stunden nach Torvalds' Mail beschrieb Kiryl Shutsemau eine Race Condition: Wird eine Seite während des Lesens aus dem Cache entfernt, neu befüllt und die Datei verlängert, kann ein Leser aus der alten Seite Daten bekommen, die nie geschrieben wurden. Die Korrektur besteht aus zwei Zeilen, die nach dem Lesen der Dateigröße prüfen, ob die Seite noch im Cache steht.

Die Begleitbeschreibung listet außerdem zehn offene Punkte selbst auf: Der Speicherverwalter sieht die wartenden Seiten nicht, ein Testprogramm von Kiryl Shutsemau brachte eine VM so zum OOM-Killer, CMA-Zuweisungen schlagen fehl, und getestet wurde nur auf einem einzigen Rechner, ohne xfstests, KASAN oder lockdep. Die Serie ist damit ein Diskussionsstand, kein fertiger Patch für den nächsten Kernel.

Ideen

Seiten erst nach einer RCU-Wartezeit freigeben, damit Leser ohne Referenzzähler auskommen.
Fehlerfälle verhindern statt sie nach dem Kopieren zu erkennen.
Nur „heiße“ Seiten, die immer wieder gelesen werden, nehmen den schnellen Pfad.
Bekannte Schwächen ehrlich in die Patch-Beschreibung schreiben, damit Reviewer gezielt suchen.
Commits mit KI-Hilfe offen als „Assisted-by“ kennzeichnen.

Einsichten

Ein Sprachmodell kann einem erfahrenen Entwickler helfen, ein jahrelang offenes Problem anzugehen, ersetzt aber nicht das Review durch Fachleute.
Gerade bei Nebenläufigkeit finden Menschen mit tiefem Wissen über den Code Fehler, die Autor und Werkzeug übersehen haben.
Transparenz über den Werkzeugeinsatz macht KI-Beiträge überprüfbar statt verdächtig.

Fakten

Im Test mit 64 Threads stiegen die Lesevorgänge von 13,3 auf 304 Millionen pro Sekunde.
Die Serie rcu-free-v3 besteht aus zehn Patches; zwei davon stammen von Kiryl Shutsemau.
Ab 1024 wartenden Seiten pro CPU erzwingt die Serie eine beschleunigte RCU-Wartezeit; die Grenze ist laut Beschreibung geschätzt.
Die von Kiryl Shutsemau vorgeschlagene Korrektur der Race Condition umfasst zwei Zeilen in mm/filemap.c.

Referenzen

Kritik

Die Zahl 23 stammt aus einem bewusst künstlichen Test; wie viel echte Arbeitslasten gewinnen, ist nicht gemessen.

Bemerkungen

Auch dieser Beitrag entstand mit Claude Code; die Quellen wurden direkt aus der Kernel-Mailingliste und Torvalds' Git-Baum gelesen.
Der Bericht von LWN über den Maintainers Summit 2026 ist bis zum 22. Oktober 2026 nur für Abonnenten frei.

Empfehlungen

KI-gestützte Änderungen genauso streng reviewen wie alle anderen, besonders bei Nebenläufigkeit.
In eigenen Projekten offen kennzeichnen, wo ein Sprachmodell mitgearbeitet hat.
Benchmark-Zahlen immer mit dem Testaufbau lesen: künstliche Spitzenwerte sagen wenig über den Alltag.

Originalartikel lesen

Im Webarchiv suchen