Torvalds utilise Claude Code pour remanier le cache de pages de Linux

Linus Torvalds, le créateur de Linux, a publié une série de correctifs du noyau qu'il dit avoir écrits avec Claude Code, l'assistant de programmation par IA d'Anthropic. Les huit correctifs modifient la façon dont Linux lit de petits morceaux de fichiers déjà présents en mémoire. Sur son portable, huit threads lisant le même fichier ont utilisé environ quatre fois moins de cycles de processeur par lecture. Rien n'est fusionné, et Torvalds énumère dix problèmes ouverts.

Ce que Torvalds a publié

Les correctifs se trouvent sur une branche appelée noref-filemap-read-with-llm dans l'arbre du noyau de Torvalds. Une branche est une ligne de modifications tenue à l'écart du code principal. Les huit correctifs de code sont datés du 7 au 10 octobre 2026 et s'appuient sur Linux 7.3-rc6, une version de test.

La description de la série est franche sur le rôle de l'IA.

Le code, les programmes de test, la relecture derrière la liste ci-dessus et le premier jet de ce texte ont été réalisés avec un assistant de programmation LLM (Claude Code) sous ma direction. Les mesures ont été effectuées sur ma machine.

Chaque correctif de code porte une ligne « Assisted-by: LLM » à côté de sa propre signature.

Hardware Busters, un site d'actualité matérielle, a rapporté l'existence de la branche le 12 octobre et note qu'elle n'a été mesurée que sur un seul portable.

Le mois dernier, Torvalds a crédité des LLM d'avoir repéré des bugs corrigés dans Linux 7.3-rc4.

Le problème que les correctifs résolvent

Linux garde en mémoire les données de fichiers récemment utilisées, dans une zone appelée cache de pages (page cache), pour ne pas avoir à relire le disque. Chaque lecture depuis ce cache marque brièvement la mémoire comme « en cours d'utilisation », puis retire la marque. Cette marque est un compteur stocké avec la page.

Quand de nombreux threads lisent en même temps le même petit fichier, tous mettent à jour ce compteur unique. Chaque cœur de processeur doit prendre à tour de rôle le même morceau de mémoire, ce qui ralentit tout le monde. Torvalds a mesuré que 99,92 % de ce trafic entre cœurs se concentrait sur une seule ligne de mémoire.

Selon Hardware Busters, Matthew Wilcox a soulevé le problème pour la première fois en 2024. Selon Torvalds, les correctifs précédents copiaient les données dans un tampon temporaire et les vérifiaient ensuite, mais ils butaient sur des cas rares que la vérification ne pouvait pas détecter.

Comment fonctionnent les correctifs

Quand une page quitte le cache de pages, Linux attend désormais avant de confier cette mémoire à quelqu'un d'autre. Il attend une période de grâce RCU, une courte fenêtre au terme de laquelle on sait que tous les lecteurs antérieurs ont fini. RCU, pour read-copy-update, est une méthode du noyau qui permet aux lecteurs de travailler sans verrous.

Comme la mémoire ne peut pas être réutilisée tant qu'un lecteur la regarde encore, la lecture n'a plus besoin du compteur. Les données sont copiées directement vers le programme. Les tentatives précédentes cherchaient à repérer des cas rares dangereux après la copie. « Différer la libération supprime ces cas au lieu de les détecter », écrit Torvalds. Si quelque chose d'inhabituel se produit, comme une page manquante ou la fin du fichier, le code revient à l'ancien chemin.

Les chiffres

Tous les chiffres viennent d'un seul portable équipé d'un Intel Core i7-8565U, qui compte 4 cœurs et 8 threads. Chaque test lisait 16 octets dans un fichier d'une page. Torvalds prévient que le portable ralentit quand il chauffe, donc les cycles par lecture se comparent plus équitablement que les lectures par seconde.

Test	Avant	Après
1 thread, cycles noyau par lecture	452-454	408-409
8 threads, cycles noyau par lecture	2 937-2 975	725-726
8 threads, lectures par seconde	9,9-10,4 millions	30-33 millions
8 threads, conflits mémoire entre cœurs (perf c2c)	30 538	101
1 thread, lecture dans un tampon pas encore en mémoire, cycles	4 117-4 188	6 543-6 593

La dernière ligne montre le coût : quand le tampon du programme n'est pas encore en mémoire, le nouveau chemin échoue une fois puis revient en arrière. « Une machine avec plus de CPU, ou avec plus d'un socket, devrait gagner davantage ; rien de plus grand n'a été mesuré », écrit Torvalds.

Ce qui reste non résolu

Retarder la réutilisation laisse une partie de la mémoire inactive. Dans un test, quatre processus ont rapidement libéré des parties d'un fichier en mémoire. La mémoire moyenne en attente est passée de 565 MiB à 15 MiB après deux correctifs supplémentaires. Ces correctifs forcent une période de grâce plus rapide dès que plus de 1 024 pages attendent sur un processeur. « La limite de 1024 pages est une estimation », écrit Torvalds.

Sa liste de problèmes connus comprend :

• L'allocateur de mémoire ne voit pas les pages en attente, si bien que l'OOM killer peut intervenir alors que des centaines de MiB sont sur le point d'être libérés.
• Les demandes de gros blocs de mémoire contigus peuvent désormais échouer avec une erreur « busy ».
• Des suites de tests comme xfstests, lockdep et KASAN n'ont pas été exécutées, et aucune machine autre que son portable n'a été essayée.
• Sur l'ordonnanceur, il écrit : « Je ne suis pas sûr que ce soit la bonne direction. »

Il qualifie la question de la mémoire de « partie de cette série la moins résolue ».

Ce que cela change pour les développeurs

• Rien ne change pour l'instant. La branche n'est pas fusionnée, et sa description ne nomme aucune version cible.
• Suivre la relecture. Les réponses des mainteneurs de la mémoire, de RCU et de l'ordonnanceur décideront si le code est intégré, modifié ou abandonné.
• Les lecteurs très sollicités gagnent le plus. Le cas mesuré est celui de nombreux threads lisant un petit fichier en cache. Les équipes qui exécutent cette charge sur des serveurs à nombreux cœurs devraient le tester.
• Un modèle pour les correctifs assistés par IA. Torvalds a nommé l'outil, signé lui-même chaque correctif, publié ses chiffres bruts et listé ce qu'il n'avait pas testé. Les équipes qui rédigent des règles pour le code écrit par IA peuvent reprendre cette forme.
• Vérifier les outils de supervision. Les lectures sur le chemin rapide sautent un tracepoint et le marquage habituel « accessed », donc les outils qui comptent les accès au cache de pages en verraient moins.