Torvalds nutzt Claude Code, um den Linux-Seitencache umzubauen

Linus Torvalds, der Schöpfer von Linux, hat eine Reihe von Kernel-Patches veröffentlicht, die nach seinen Angaben mit Claude Code geschrieben wurden, dem KI-Coding-Assistenten von Anthropic. Die acht Patches ändern, wie Linux kleine Teile von Dateien liest, die schon im Arbeitsspeicher liegen. Auf seinem Laptop brauchten acht Threads, die dieselbe Datei lasen, pro Lesezugriff etwa viermal weniger Prozessorzyklen. Nichts davon ist übernommen, und Torvalds nennt zehn offene Probleme.

Was Torvalds veröffentlicht hat

Die Patches liegen auf einem Branch namens noref-filemap-read-with-llm in Torvalds' eigenem Kernel-Tree. Ein Branch ist eine Reihe von Änderungen, die getrennt vom Hauptcode geführt wird. Die acht Code-Patches sind auf den 7. bis 10. Oktober 2026 datiert und bauen auf Linux 7.3-rc6 auf, einer Testversion.

Die Beschreibung der Serie ist offen über die Rolle der KI.

Der Code, die Testprogramme, die Prüfung hinter der obigen Liste und der erste Entwurf dieses Textes wurden unter meiner Anleitung mit einem LLM-Coding-Assistenten (Claude Code) erstellt. Die Messungen wurden auf meinem Rechner durchgeführt.

Jeder Code-Patch trägt neben seiner eigenen Signatur eine Zeile „Assisted-by: LLM".

Hardware Busters, eine Hardware-Nachrichtenseite, berichtete am 12. Oktober über den Branch und merkt an, dass nur auf einem einzigen Laptop gemessen wurde.

Im vergangenen Monat schrieb Torvalds LLMs zu, Fehler gefunden zu haben, die in Linux 7.3-rc4 behoben wurden.

Das Problem, das die Patches lösen

Linux hält zuletzt genutzte Dateidaten im Arbeitsspeicher, in einem Bereich namens Page Cache (Seitencache), damit die Platte nicht erneut gelesen werden muss. Jeder Lesezugriff auf diesen Cache markiert den Speicher kurz als „in Benutzung" und hebt die Markierung dann wieder auf. Diese Markierung ist ein Zähler, der bei der Seite gespeichert ist.

Wenn viele Threads gleichzeitig dieselbe kleine Datei lesen, aktualisieren alle diesen einen Zähler. Jeder Prozessorkern muss dasselbe Stück Speicher der Reihe nach übernehmen, was alle ausbremst. Torvalds hat gemessen, dass 99,92 % dieses Verkehrs zwischen den Kernen auf eine einzige Speicherzeile entfielen.

Laut Hardware Busters hat Matthew Wilcox das Problem 2024 zuerst aufgeworfen. Laut Torvalds kopierten frühere Lösungen die Daten in einen temporären Puffer und prüften sie danach, scheiterten aber an seltenen Fällen, die die Prüfung nicht erfassen konnte.

Wie die Patches funktionieren

Wenn eine Seite den Page Cache verlässt, wartet Linux jetzt, bevor es diesen Speicher an jemand anderen vergibt. Es wartet auf eine RCU-Grace-Period, ein kurzes Zeitfenster, nach dem bekannt ist, dass jeder frühere Leser fertig ist. RCU, kurz für Read-Copy-Update, ist eine Kernel-Methode, mit der Leser ohne Sperren arbeiten können.

Weil der Speicher nicht wiederverwendet werden kann, solange ein Leser ihn noch ansieht, braucht der Lesezugriff den Zähler nicht mehr. Die Daten werden direkt an das Programm kopiert. Frühere Versuche wollten seltene unsichere Fälle nach dem Kopieren abfangen. „Das Aufschieben der Freigabe beseitigt diese Fälle, statt sie zu erkennen", schreibt Torvalds. Wenn etwas Ungewöhnliches passiert, etwa eine fehlende Seite oder das Dateiende, fällt der Code auf den alten Pfad zurück.

Die Zahlen

Alle Werte stammen von einem Laptop mit Intel Core i7-8565U, der 4 Kerne und 8 Threads hat. Jeder Test las 16 Byte aus einer Datei mit einer Seite. Torvalds warnt, dass der Laptop bei Hitze langsamer wird, daher sind Zyklen pro Lesezugriff besser vergleichbar als Lesezugriffe pro Sekunde.

Test	Vorher	Nachher
1 Thread, Kernel-Zyklen pro Lesezugriff	452-454	408-409
8 Threads, Kernel-Zyklen pro Lesezugriff	2.937-2.975	725-726
8 Threads, Lesezugriffe pro Sekunde	9,9-10,4 Millionen	30-33 Millionen
8 Threads, Speicherkonflikte zwischen Kernen (perf c2c)	30.538	101
1 Thread, Lesen in einen Puffer, der noch nicht im Speicher ist, Zyklen	4.117-4.188	6.543-6.593

Die letzte Zeile zeigt die Kosten: Wenn der Puffer des Programms noch nicht im Speicher ist, scheitert der neue Pfad einmal und fällt zurück. „Eine Maschine mit mehr CPUs oder mit mehr als einem Sockel sollte mehr gewinnen; größere Systeme wurden nicht gemessen", schreibt Torvalds.

Was noch ungelöst ist

Das Aufschieben der Wiederverwendung lässt etwas Speicher ungenutzt. In einem Test gaben vier Prozesse schnell Teile einer Datei im Arbeitsspeicher frei. Der durchschnittlich wartende Speicher sank nach zwei zusätzlichen Patches von 565 MiB auf 15 MiB. Diese Patches erzwingen eine schnellere Grace-Period, sobald mehr als 1.024 Seiten auf einem Prozessor warten. „Die Grenze von 1024 Seiten ist geraten", schreibt Torvalds.

Seine Liste bekannter Probleme umfasst:

• Der Speicher-Allocator sieht die wartenden Seiten nicht, daher kann der Out-of-Memory-Killer eingreifen, obwohl bald Hunderte MiB frei werden.
• Anfragen nach großen zusammenhängenden Speicherblöcken können jetzt mit einem „busy"-Fehler scheitern.
• Test-Suiten wie xfstests, lockdep und KASAN wurden nicht ausgeführt, und außer seinem Laptop wurde keine Maschine ausprobiert.
• Beim Scheduler schreibt er: „Ich bin nicht sicher, dass dies die Richtung ist."

Die Speicherfrage nennt er „den am wenigsten gelösten Teil dieser Serie".

Was das für Entwickler bedeutet

• Noch ändert sich nichts. Der Branch ist nicht übernommen, und seine Beschreibung nennt kein Zielrelease.
• Die Review beobachten. Antworten der Maintainer für Speicher, RCU und Scheduler entscheiden, ob der Code landet, geändert oder verworfen wird.
• Stark ausgelastete Leser profitieren am meisten. Der gemessene Fall sind viele Threads, die eine kleine zwischengespeicherte Datei lesen. Teams, die diese Last auf Servern mit vielen Kernen fahren, sollten es testen.
• Eine Vorlage für KI-unterstützte Patches. Torvalds nannte das Werkzeug, signierte jeden Patch selbst, veröffentlichte seine Rohwerte und listete auf, was er nicht getestet hatte. Teams, die Regeln für KI-geschriebenen Code aufstellen, können diese Form übernehmen.
• Monitoring-Werkzeuge prüfen. Lesezugriffe auf dem schnellen Pfad überspringen einen Tracepoint und die übliche „accessed"-Markierung, daher würden Werkzeuge, die Page-Cache-Treffer zählen, weniger davon sehen.