senn-techTorvalds lässt Claude Code den Lesepfad des Page-Cache umbauen: Was die Zahlen belegen und was nicht
Am 10. und 11. Oktober 2026 hat Linus Torvalds in seinem Repository torvalds/linux.git einen Branch angelegt, in dem er sonst nur master führt. Der Branch heißt noref-filemap-read-with-llm. Phoronix hat ihn am 11. Oktober gemeldet, Linuxiac am 12. Oktober mit den Messwerten aus der Commit-Nachricht. Dieser Beitrag beruht auf diesen Berichten. Die Commit-Nachricht selbst und den Branch haben wir nicht gelesen, eigene Messungen gibt es nicht.
Was die Patches ändern
Der Titel der Serie lautet „mm: read from the page cache without folio references". Es sind nach Linuxiac acht experimentelle Patches auf Basis von Linux 7.3-rc6. Sie nutzen den Mechanismus Read-Copy-Update, damit bestimmte Lesezugriffe ohne Referenzzähler auf die Speicherseite (folio) auskommen. Der Hintergrund: Wenn viele Threads kleine Stücke derselben Datei aus dem Page-Cache lesen, erhöhen und senken alle denselben Zähler. Der Zähler ist dann der Engpass, nicht das Lesen selbst.
Zur Rolle der KI schreibt Torvalds in der Commit-Nachricht laut Phoronix und Linuxiac, Code, Testprogramme, Prüfung und der erste Entwurf des Textes seien mit einem LLM-Coding-Assistenten, Claude Code, unter seiner Anleitung entstanden, und die Messungen seien auf seinem Rechner gelaufen.
Was gemessen wurde
Linuxiac gibt die Werte aus der Commit-Nachricht wieder: ein Laptop mit Intel Core i7-8565U (4 Kerne, 8 Threads), ext4, einige Schutzmaßnahmen des Kernels abgeschaltet.
Bei acht Threads, die je 16 Byte aus derselben zwischengespeicherten Datei lesen, steigt der Durchsatz von etwa 10 Millionen auf 30 bis 33 Millionen Lesevorgänge pro Sekunde, rund das Dreifache. Bei vier Threads auf getrennten Kernen von 9 bis 12 auf 25 bis 26 Millionen. Ein einzelner Thread gewinnt kaum, von 8 auf knapp 9 Millionen.
Was fehlt
Die Commit-Nachricht nennt laut Linuxiac offene Punkte: Verhalten bei der Speicherzuteilung, Kompatibilität, mögliche Regressionen und die Kosten dafür, dass Speicher später wiederverwendet wird. Die Patches können in einigen Fällen zusätzlichen Aufwand verursachen, vor allem beim Lesen fehlender Seiten. Gemessen wurde auf einer einzelnen, älteren Maschine, nicht auf Servern mit vielen Kernen und nicht mit anderen Dateisystemen.
Ein Bericht von The New Stack vom 14. Oktober trägt die Überschrift, Reviewer hätten in dem Code eine Race Condition gefunden. Den Artikeltext konnten wir nicht abrufen, wir geben die Überschrift deshalb nur als Behauptung wieder. Wer die Aussage braucht, liest den Bericht im Original.
Was Betreiber und Entwickler mitnehmen
- Die Zahl „dreimal" gilt für einen Mikrobenchmark mit viel Konkurrenz auf demselben Zähler. Wer Datenbanken oder Webserver betreibt, kann den Effekt nicht daraus ableiten. Eine Aussage über Produktionslast verlangt Messung auf der eigenen Last.
- Entscheidend ist der Umgang mit dem KI-Anteil. Torvalds legt offen, was die KI schrieb, was er gemessen hat und welche Punkte offen sind. Das ist das Muster, an dem sich KI-gestützte Änderungen in der eigenen Firma messen lassen: Wer hat geprüft, auf welcher Hardware wurde gemessen, was ist ungeklärt.
- Ein Race, das erst ein Reviewer findet, zeigt, wo der Aufwand liegt. KI senkt den Aufwand, den ersten Entwurf zu schreiben. Das Prüfen des Entwurfs bleibt Arbeit für Menschen mit Kenntnis der Nebenläufigkeit.
- Experimente im Kernel kommen in Distributionen erst nach Merge und Test. Auf Servern ist derzeit nichts zu tun.
Was Foren sagen
Die Phoronix-Meldung steht auf Hacker News mit 32 und mit 5 Punkten bei höchstens 2 Kommentaren, der Beitrag von Startup Fortune hat 17 Punkte und 12 Kommentare (Thread). Eine fachliche Diskussion der Patches haben wir dort nicht gefunden. Die Beurteilung des Codes läuft auf der Kernel-Mailingliste, die wir nicht gelesen haben.
So haben wir geprüft
Am 16. Oktober 2026 haben wir die Berichte von Phoronix und Linuxiac gelesen. Phoronix nennt keine Zahlen im Text, nur ein Diagramm, die Messwerte stammen daher aus Linuxiac. Der Artikel von The New Stack war nicht lesbar, die Überschrift ist die einzige Information daraus. Die Commit-Nachricht und den Branch haben wir nicht geprüft.
Weiterführende Quellen
Berichte
- Phoronix, Linus Torvalds Working on a Hefty Linux Kernel Improvement with Claude Code, 11.10.2026
- Linuxiac, Linus Torvalds Experiments with AI-Generated Kernel Code, Sees 3x Speedup, 12.10.2026
- The New Stack, Linus Torvalds let Claude Code fix the Linux page cache. Then reviewers found a race, 14.10.2026 (nur Überschrift gelesen)
- Startup Fortune, Linus Torvalds used Claude Code to rewrite how Linux reads cached files, 12.10.2026
Community
- Hacker News, 17 Punkte und 12 Kommentare: news.ycombinator.com/item?id=50062224
- Hacker News, 32 Punkte (Phoronix): news.ycombinator.com/item?id=50050367
Ist der Code im Linux-Kernel?+
Nein. Es ist ein experimenteller Branch mit dem Namen noref-filemap-read-with-llm in Torvalds' Repository. Phoronix schreibt, es sei offen, ob er im Merge-Fenster für Linux 7.4 landet. Eine Aufnahme in den Hauptzweig ist nicht belegt.
Heißt dreimal schneller, dass Linux dreimal schneller wird?+
Nein. Gemessen wurde ein enger Fall: viele Threads lesen kleine Stücke derselben zwischengespeicherten Datei, auf einem älteren Laptop mit abgeschalteten Schutzmaßnahmen des Kernels. Bei einem einzelnen Thread ist der Gewinn klein, und die Patches kosten in einigen Fällen zusätzlich, etwa beim Lesen fehlender Seiten.
Hat die KI den Code allein geschrieben?+
Torvalds schreibt in der Commit-Nachricht, Code, Testprogramme, Prüfung und der erste Entwurf des Textes seien mit Claude Code unter seiner Anleitung entstanden. Die Messungen habe er auf seinem Rechner gemacht. Ein Bericht der New Stack meldet in der Überschrift, Reviewer hätten eine Race Condition gefunden, den Artikeltext konnten wir nicht lesen.