Linus Torvalds, der Schöpfer von Linux und Hauptverantwortliche für die Kernel-Entwicklung, nutzte Anthropics Werkzeug Claude Code, um bei der Behebung eines seit mehr als zwei Jahren bestehenden Engpasses im Dateilesepfad zu helfen. Eine Serie aus 10 Patches erzielte auf einem Threadripper-System mit 64 Kernen in einem synthetischen Test eine bis zu 23-fache Verbesserung der Leserate. Später entdeckten Linux-Kernel-Reviewer jedoch eine Race Condition und warfen Fragen zur Sicherheit des Designs für die Speicherwiederherstellung auf. Das bedeutet, dass die Patches noch nicht integriert wurden.
Problem mit Referenzzählern des Seitenspeichers
Die Arbeit betrifft eine Konkurrenzsituation bei Referenzzählern von Objekten, die als Folios bezeichnet werden und sich innerhalb des Page Cache befinden. Dabei handelt es sich um eine Schicht, die aus Dateien gelesene Daten für einen schnelleren Zugriff bereithält. Der Engpass wurde 2024 gemeldet, nachdem er in der Arbeitslast eines Kunden aufgetreten war. Tests auf Torvalds’ Laptop zeigten, dass diese Konkurrenzsituation in einem Test mit acht Threads 99,92 % der HITM-Operationen über die Kerne ausmachte.
Torvalds sagte, er habe 18 Monate lang eine fehlerhafte Version seines früheren Fixes für das Problem ausgeführt, während andere Entwickler bei ihren Versuchen auf Probleme stießen. Die neuen Patches zielen darauf ab, Erhöhungen und Verringerungen der Folio-Referenzen aus dem meistgenutzten Pfad für das Lesen aus dem Cache zu entfernen. Torvalds warnte jedoch, dass die Gewinne bei realistischen Arbeitslasten im Vergleich zum synthetischen Test deutlich geringer ausfallen würden.
Die Rolle von Claude Code und die Grenzen des Ergebnisses
In Torvalds’ Baum erschien ein experimenteller Branch mit dem Namen noref-filemap-read-with-llm. Die Serie enthielt anschließend eine Erläuterung der Rolle von Claude Code. Nach Angaben von Torvalds schrieb das Werkzeug die Implementierung, die Tests und die erste Dokumentation und überprüfte den Code unter seiner Anleitung, während er selbst die Leistungstests ausführte.
Die erste Serie steigerte die Leserate auf seinem Laptop von etwa 10 Millionen auf 33 Millionen Lesevorgänge pro Sekunde und senkte die Zahl der Kernel-Zyklen pro Lesevorgang von ungefähr 2.950 auf 725. Die überarbeitete Serie erhöhte die Leistung auf einem Threadripper-System unter hoher Last von 13,3 Millionen auf 304 Millionen Lesevorgänge pro Sekunde. Gleichzeitig sank die Zahl der Zyklen pro Lesevorgang von etwa 20.000 auf 735.
Warum Leistungszahlen nicht ausreichen
Die Verbesserung brachte potenzielle Kosten mit sich. Die erste Implementierung erzwang eine beschleunigte Wartephase, sobald die CPU 1.024 Seiten überschritt, deren Wiederherstellung ausstand. Außerdem führten Lesevorgänge in nicht zugeordneten Benutzerspeicherseiten zu einem zusätzlichen Fehler, bevor zum bestehenden Pfad zurückgekehrt wurde. Dadurch stiegen die Kosten eines Single-Thread-Lesevorgangs von 16 Byte von etwa 4.150 auf 6.550 Zyklen. Ob dieser Rückschritt in der Version rcu-free-v3 bestehen bleibt, ist noch nicht geklärt.
Die Überprüfung enthüllte das wichtigste Risiko
Matthew Wilcox beanstandete die Verwendung des neuen Flags PG_rcu_free und schlug eine Alternative vor, die auf dem Seitentyp und einem anderen Mechanismus zur Wiederherstellung inaktiver Folios basiert. Kiryl Shutsemau schlug außerdem vor, das Flag auf 64-Bit-Systeme zu beschränken, eine Richtung, die David Hildenbrand unterstützte.
Shutsemau entdeckte zudem eine Race Condition in der Funktion filemap_read_rcu_batch(): Das Ersetzen eines Folios und eine anschließende Vergrößerung der Dateigröße könnten Daten sichtbar machen, die tatsächlich noch nicht geschrieben wurden. Torvalds schlug vor, die Dateigröße früher zu lesen und die Prüfungen zusammenzufassen. Dies wurde in einen überarbeiteten Patch aufgenommen.
Die redaktionelle Einordnung von certi.news: Der Fall zeigt, dass KI-Programmierwerkzeuge schnell erhebliche Verbesserungen in Kerneltests erreichen können. Sie machen jedoch keine spezialisierte Überprüfung überflüssig, die Nebenläufigkeit und den Lebenszyklus des Speichers versteht. Die Rekordzahlen belegen hier einen Gewinn in einer bestimmten Umgebung, nicht automatisch die Bereitschaft zur Integration oder eine Garantie für die Sicherheit der Implementierung.