Dass Linus Torvalds wenig Berührungsängste mit neuer Technik hat, ist bekannt. Neu ist, wie offen er diesmal damit umgeht: Für einen experimentellen Kernel-Patch gegen eine jahrzehntealte Performance-Bremse hat er nach eigener Aussage Claude Code als Werkzeug eingesetzt — und ein Meta-Ingenieur hat die Arbeit seitdem deutlich beschleunigt.
DAS PROBLEM: Ein Zähler, um den sich alle streiten
Im Linux-Kernel verwaltet der sogenannte Page Cache, welche Dateiinhalte im Arbeitsspeicher zwischengespeichert sind. Liest eine einzelne Datei von vielen Threads gleichzeitig immer wieder kleine Häppchen, kommt es zu einem Engpass: Alle Threads greifen auf denselben Referenzzähler der jeweiligen „Folio“ (eine interne Speichereinheit) zu — und blockieren sich dabei gegenseitig.
Torvalds veröffentlichte dafür einen experimentellen Branch namens noref-filemap-read-with-llm, der genau diese Kontention umgeht: Ein RCU-basierter Lesepfad erlaubt es, aus dem Cache zu lesen, ohne für jeden einzelnen Lesevorgang den Referenzzähler anzufassen.
KI SCHREIBT MIT — UND TORVALDS SAGT ES OFFEN
In seinem Begleittext zur Patch-Serie schreibt Torvalds wörtlich: „The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction.“ — der Code, die Testprogramme, die Review-Arbeit und der erste Entwurf dieses Textes entstanden also mit Claude Code, aber ausdrücklich unter seiner eigenen Anleitung, nicht autonom.
UND DANN KAM META
Richtig spannend wird die Geschichte durch die Fortsetzung: Am 19. Oktober veröffentlichte der Meta-Ingenieur Kiryl Shutsemau eine deutlich erweiterte Version als 18-Patch-RFC, die direkt auf Torvalds‘ Arbeit aufbaut. Von diesen 18 Patches stammen 11 von Shutsemau und 7 von Torvalds selbst — zusammen ändern sie 20 Dateien, fügen 770 Zeilen hinzu und entfernen 92. Im Zentrum steht die Kernel-Funktion filemap_read(), die hinter ganz gewöhnlichen Datei-Lesevorgängen steckt.
Die Zahlen, die Shutsemau dabei vorlegt, sind deutlich: In einem 64-Thread-Benchmark auf ext4 stiegen die kleinen, wiederholten Lesevorgänge von rund 15 Millionen auf etwa 70 Millionen pro Sekunde — mehr als das Vierfache.
WAS DAS PRAKTISCH BEDEUTET
Noch handelt es sich um ein experimentelles Patch-Set, das nicht im Mainline-Kernel gelandet ist. Ob und wann die Änderungen für ein reguläres Merge-Fenster — frühestens Linux 7.4 — infrage kommen, ist offen. Praktisch relevant wird die Optimierung vor allem für Workloads mit sehr vielen gleichzeitigen, kleinen Lesezugriffen auf dieselbe Datei — etwa stark parallelisierte Datenbank- oder Web-Server-Szenarien.
WARUM DIESE GESCHICHTE MEHR IST ALS EINE PERFORMANCE-NOTIZ
Bemerkenswert ist weniger der Patch selbst als das, was er über den Stand von KI-gestützter Kernel-Entwicklung aussagt: Nicht irgendein Hobby-Projekt, sondern der Kernel-Maintainer selbst nutzt offen einen KI-Assistenten — und ein Ingenieur eines der größten Linux-Nutzer der Welt baut die Arbeit innerhalb von Tagen produktiv weiter aus. Das ist ein konkreter Beleg dafür, dass KI-Unterstützung in der Kernel-Entwicklung von der Neugierde zur echten, kollaborativen Praxis wird — selbst ganz oben in der Hierarchie.
FAZIT: Vom Experiment zur ernstzunehmenden Optimierung
In nicht einmal zehn Tagen wurde aus einem von Torvalds mit KI-Unterstützung angestoßenen Experiment ein Patch-Set mit vierfacher Performance-Verbesserung, an dem jetzt mehrere erfahrene Kernel-Entwickler mitarbeiten. Ob es am Ende in den Mainline-Kernel schafft, bleibt offen — die Richtung ist es nicht.