Ein Laptop mit vier Kernen, acht Patches und ein Satz, der die Kernel-Community aufhorchen lässt: "Tools: Claude Code". Mit dieser schlichten Zeile im Cover-Letter einer neuen Branch hat Linus Torvalds am 10. Oktober 2026 offen gemacht, dass ein KI-Coding-Agent an einer Memory-Management-Patch-Serie für den Linux-Kernel mitgearbeitet hat. Das Thema Linux Kernel KI ist damit nicht länger eine abstrakte Zukunftsfrage, sondern ein konkreter, nachvollziehbarer Branch im eigenen Repository des Kernel-Erfinders, mit Messdaten, offenen Fragen und einem klar benannten Trade-off.
Der Branch trägt den Namen "noref-filemap-read-with-llm" und greift tief in die Art ein, wie der Kernel Daten aus dem Page Cache liest. Entdeckt wurde er vom Phoronix-Redakteur Michael Larabel, der die Veröffentlichung öffentlich machte. Für Entwickler, Systemprogrammierer und alle, die sich für die technische Zukunft des Kernels interessieren, liefert dieser Fall gleich zwei Geschichten: eine über Performance-Optimierung im Page Cache und eine über den Einsatz von KI-Agenten in einem der kritischsten Software-Projekte der Welt.
Inhaltsverzeichnis
Key Takeaways
- Linus Torvalds veröffentlichte am 10. Oktober 2026 den Branch "noref-filemap-read-with-llm" mit acht Patches für die
filemap_read-Funktion des Linux-Kernels. - Die Patch-Serie reduziert Kontention bei vielen gleichzeitigen kleinen Lesezugriffen auf dieselbe Datei, gemessen auf Torvalds' eigenem Laptop (Intel Core i7-8565U).
- Kernel-Zyklen pro Lesevorgang bei 8 Threads fielen von rund 2950 auf rund 725 Zyklen, der Durchsatz stieg auf das rund Dreifache.
- Torvalds benennt explizit ein Sicherheitsventil gegen Speicherdruck sowie eine Regression bei ungemappten Seiten.
- Im Cover-Letter bestätigt Torvalds, dass Code, Testprogramme, Review-Arbeit und der erste Entwurf des Textes mit Anthropics Claude Code entstanden sind, ein neuer Schritt für das Thema Linux Kernel KI.
Was ist "noref-filemap-read-with-llm"?
Der Branch basiert auf Linux 7.3-rc6 und liegt im persönlichen Git-Repository von Linus Torvalds. Der Name verrät bereits das Grundprinzip: "noref" steht für den Verzicht auf klassische Referenzzählung beim Lesen, "filemap-read" verweist auf die betroffene Kernel-Funktion filemap_read, und "with-llm" macht transparent, dass ein Sprachmodell am Entstehungsprozess beteiligt war.
Die acht Patches ändern, wie der Kernel Daten aus dem Page Cache an lesende Prozesse ausliefert. Das Problem dahinter ist nicht neu: Matthew Wilcox meldete es bereits 2024, ausgelöst durch einen realen Kundenworkload, bei dem viele Threads gleichzeitig kleine Datenmengen aus derselben Datei lasen.
Das technische Problem: Kontention im Page Cache
Wenn mehrere Threads gleichzeitig aus derselben Datei lesen, muss der Kernel sicherstellen, dass die zugrunde liegende Speicherseite (Folio) nicht während des Lesevorgangs verschwindet. Klassischerweise geschieht das über atomare Referenzzähl-Operationen wie lock cmpxchg und lock decl. Diese Operationen sind zwar korrekt, erzeugen aber bei vielen parallelen Zugriffen auf dieselbe Cache-Zeile erhebliche Kontention zwischen den CPU-Kernen, ein Effekt, der mit steigender Thread-Zahl überproportional zunimmt.
Genau dieses Verhalten beschrieb Matthew Wilcox 2024 anhand eines Kundenworkloads: Viele Threads, kleine Lesezugriffe, eine gemeinsame Datei, ein Muster, das in der Praxis häufiger vorkommt, als man zunächst vermuten würde, etwa bei stark parallelisierten Server-Anwendungen.
Die Kernidee hinter der Linux Kernel KI Patch-Serie
Der zentrale Trick der Patch-Serie ist elegant und riskant zugleich: Eine Folio, die aus dem Page Cache entfernt wird, wird nicht sofort an den Page-Allocator zurückgegeben. Stattdessen wartet sie, bis eine RCU-Grace-Period (Read-Copy-Update) abgelaufen ist.
"Der am wenigsten gelöste Teil der Serie", so bezeichnet Torvalds selbst den Umstand, dass Speicher dadurch länger im System verweilt, bevor er wiederverwendet werden kann.
Während dieser Wartezeit kann ein lesender Thread innerhalb einer RCU-Read-Side-Section, bei deaktivierten Page-Faults, direkt aus dem Page Cache kopieren, ganz ohne die teuren atomaren Referenzzähl-Operationen. Weil die Folio durch die RCU-Grace-Period garantiert noch gültig ist, braucht der Reader keinen Lock und keine Zählung. Das ist der Kern der Performance-Verbesserung.
Messergebnisse: Was die Linux Kernel KI Optimierung wirklich bringt
Alle Zahlen stammen von Torvalds' eigenem Laptop, einem Intel Core i7-8565U mit vier Kernen und acht Threads, Mitigations deaktiviert. Getestet wurde unter anderem mit 8 Threads, die per pread() jeweils 16 Byte aus einer gemeinsamen Datei lasen.
| Messgröße | Vorher | Nachher | Veränderung |
|---|---|---|---|
| Kernel-Zyklen pro Read (8 Threads) | ca. 2950 | ca. 725 | deutlich reduziert |
| Durchsatz (Reads/Sekunde) | 9,9-10,4 Mio. | 30-33 Mio. | ca. 3x |
| Cross-Core Load-HITMs (perf c2c) | 30.538 | 101 | massiv reduziert |
| Zyklen pro Read (1 Thread) | 452-454 | 408-409 | ca. 10 % günstiger |
Besonders auffällig ist der Rückgang der Cross-Core Load-HITMs, gemessen mit dem Profiling-Werkzeug perf c2c. Dieser Wert zeigt an, wie oft CPU-Kerne auf dieselbe Cache-Zeile zugreifen und sich dabei gegenseitig blockieren. Ein Rückgang von über 30.000 auf gerade einmal 101 Ereignisse bestätigt, dass die Kontention praktisch verschwunden ist.
Auch bei nur einem einzelnen Thread, also ganz ohne Parallelität, bringt die Änderung einen kleinen, aber messbaren Vorteil von rund 10 Prozent weniger Zyklen pro Lesevorgang.
Trade-off und Sicherheitsventil
Der Verzicht auf sofortige Speicherfreigabe hat einen Preis: Speicher bleibt länger "wartend" im System, bevor er dem Page-Allocator wieder zur Verfügung steht. Dieser Umstand birgt theoretisch das Risiko, dass unter Speicherdruck zu viele Seiten in der Warteschlange landen.
Um dieses Risiko zu entschärfen, führen zwei der acht Patches ein Sicherheitsventil ein. Die Regel ist einfach formuliert:
- Sobald eine CPU mehr als 1024 Seiten in ihrer Warteschlange angesammelt hat, erzwingt ein Worker-Prozess eine beschleunigte RCU-Grace-Period.
- Der Speicher wird dadurch zügig freigegeben, bevor Engpässe entstehen.
Die Wirksamkeit dieses Mechanismus wurde in einem Stresstest mit einer 2-GiB-VM überprüft. Das Ergebnis ist eindeutig:
| Version | 1 CPU | 2 CPUs | 4 CPUs | 8 CPUs |
|---|---|---|---|---|
| 8-Patch-Version (mit Sicherheitsventil) | fehlerfrei | fehlerfrei | fehlerfrei | fehlerfrei |
| 6-Patch-Version (ohne Sicherheitsventil) | fehlerfrei | fehlerfrei | OOM-Killer | OOM-Killer |
Ohne das Sicherheitsventil löste die reduzierte 6-Patch-Version bei 4 und 8 CPUs den Out-of-Memory-Killer aus, ein klarer Beleg dafür, dass die beiden zusätzlichen Patches keine kosmetische Ergänzung sind, sondern eine funktionale Notwendigkeit für stabilen Betrieb unter Speicherdruck.
Die Regression: Ein Preis für die Beschleunigung
Keine Optimierung ohne Kompromiss. Die neue Leseweise bringt eine messbare Regression in einem spezifischen Szenario mit sich: Greift ein Prozess auf eine Nutzerseite zu, die noch nicht gemappt ist, braucht dieser Zugriff jetzt eine zusätzliche fehlgeschlagene Exception, bevor der alte, bekannte Codepfad greift.
Konkret steigen die Zyklen bei 16-Byte-Single-Thread-Reads auf eine ungemappte Seite von etwa 4150 auf etwa 6550 Zyklen. Das ist ein substanzieller Anstieg für diesen speziellen Fall, der im Vergleich zur massiven Verbesserung bei konkurrierenden Lesezugriffen jedoch bewusst in Kauf genommen wird. Torvalds dokumentiert diese Regression offen im Cover-Letter, statt sie zu verschweigen, ein Hinweis auf den sachlichen, technisch transparenten Charakter der gesamten Patch-Serie.
Linux Kernel KI im Cover-Letter: Claude Code als Werkzeug
Der eigentliche Aufreger für viele Beobachter ist nicht die Performance-Zahl, sondern der "Tools"-Abschnitt im Cover-Letter der Patch-Serie. Dort beschreibt Torvalds explizit, dass folgende Arbeiten mit Anthropics Claude Code, einem KI-Coding-Agenten, unter seiner Anleitung entstanden sind:
- der eigentliche Patch-Code
- die Testprogramme zur Verifikation
- die Review-Arbeit hinter der Liste offener Probleme
- der erste Entwurf des Cover-Letter-Texts selbst
Die Messungen selbst liefen weiterhin auf Torvalds' eigener Maschine, nicht in einer KI-Simulation. Das bedeutet: Die KI war Werkzeug im Entwicklungsprozess, nicht Ersatz für die reale Validierung der Ergebnisse.
Torvalds hat zuvor bereits KI-Werkzeuge für Kernel-Debugging genutzt. Neu ist jedoch, dass eine komplette Memory-Management-Patch-Serie im eigenen Tree einem KI-Agenten als Mitwirkenden zugeschrieben wird. Für das Thema Linux Kernel KI markiert das einen Wendepunkt: Es geht nicht mehr nur um Code-Vervollständigung oder Fehlersuche, sondern um die aktive Mitgestaltung einer architektonisch anspruchsvollen Änderung am Herzstück des Betriebssystems.
Status: Noch nicht gemerged
Trotz der beeindruckenden Zahlen ist der Branch "noref-filemap-read-with-llm" ausdrücklich kein fertiges Feature. Mehrere Einschränkungen sind zu beachten:
- Die Messungen stammen von einem einzigen Laptop, nicht von einer breiten Testumgebung.
- Torvalds benennt selbst offene Design-Fragen, etwa ob es einen besseren RCU-Hook für diesen Anwendungsfall gibt.
- Unklar sind auch die Kosten der Inter-Processor-Interrupts (IPIs) bei
synchronize_rcu_expedited(), die für die beschleunigte Grace-Period im Sicherheitsventil nötig sind.
Der Branch dient damit als Diskussionsgrundlage für die Kernel-Mailingliste, nicht als Merge-Kandidat für die nächste stabile Version. Diese Vorsicht ist typisch für den Entwicklungsprozess des Kernels, bei dem radikale Änderungen an zentralen Subsystemen wie dem Page Cache traditionell lange Reifezeiten durchlaufen, bevor sie überhaupt zur Aufnahme vorgeschlagen werden.
Was bedeutet das für die Zukunft von Linux Kernel KI?
Der Fall "noref-filemap-read-with-llm" zeigt, wie sich die Rolle von KI-Agenten in der Systemprogrammierung verschiebt. Statt nur Boilerplate-Code zu generieren oder Syntaxfehler zu finden, übernimmt ein Werkzeug wie Claude Code hier Aufgaben, die traditionell tiefes Verständnis der Kernel-Internals erfordern: das Schreiben von Testprogrammen für Nebenläufigkeitsszenarien, die strukturierte Review-Arbeit an einer Liste offener Probleme und sogar das Verfassen technischer Dokumentation.
Wer wissen will, wie sich verschiedene KI-Coding-Agenten in der Praxis schlagen, findet einen Einstieg in unserem Vergleich von KI-Coding-Agenten. Entscheidend bleibt dabei die menschliche Validierung. Torvalds hat die Messungen selbst durchgeführt, die Zahlen überprüft und die offenen Fragen transparent benannt. Linux Kernel KI bedeutet in diesem Fall nicht Automatisierung ohne Aufsicht, sondern eine Arbeitsteilung, bei der die KI als Werkzeug unter menschlicher Anleitung fungiert, mit allen Chancen und ungelösten Fragen, die ein so früher Schritt zwangsläufig mit sich bringt.
Fazit und nächste Schritte
Die Patch-Serie "noref-filemap-read-with-llm" liefert gleich zwei relevante Erkenntnisse für die Linux-Community. Erstens: Die technische Optimierung selbst ist substanziell, ein bis zu dreifacher Durchsatzgewinn bei konkurrierenden kleinen Lesezugriffen ist für viele parallele Workloads ein erheblicher Fortschritt, auch wenn die Regression bei ungemappten Seiten und die offenen Design-Fragen rund um RCU-Grace-Periods vor einem Merge noch gelöst werden müssen. Zweitens: Der offene Umgang mit dem Einsatz von Claude Code im Entwicklungsprozess setzt einen Präzedenzfall für Transparenz beim Thema Linux Kernel KI.
Für Entwickler und Systemprogrammierer lohnt sich jetzt ein Blick in den Branch selbst, insbesondere in den vollständigen Cover-Letter mit der Liste offener Probleme. Wer sich mit Page-Cache-Interna, RCU-Mechanismen oder Performance-Profiling mit perf c2c beschäftigt, findet hier ein konkretes, gut dokumentiertes Fallbeispiel. Die Diskussion auf der Kernel-Mailingliste dürfte in den kommenden Wochen zeigen, ob die offenen Fragen zu RCU-Hooks und IPI-Kosten gelöst werden können, und ob der Branch den Weg in eine spätere Kernel-Version findet.
Quellen
- Offizieller Kernel-Commit und Cover-Letter, kernel.org, 2026: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=noref-filemap-read-with-llm&id=4c0f3697118eb3a708ea79175f7f07c43339bfa
- HWBusters, "Linus Torvalds Uses Claude Code To Rework The Linux Page Cache, Tripling Small Read Throughput", 2026: https://hwbusters.com/news/linus-torvalds-uses-claude-code-to-rework-the-linux-page-cache-tripling-small-read-throughput/
