Avec une IA, Linus Torvalds s’attaque à un goulot du noyau Linux

Quand des dizaines de programmes lisent le même fichier en même temps, le noyau Linux les ralentit les uns les autres pour une simple question de comptabilité. Linus Torvalds, le créateur du système, a soumis mardi 13 octobre à ses pairs dix correctifs qui visent à lever ce frein, mis au point avec un assistant de programmation fondé sur l’IA. Son courriel, adressé aux développeurs de la gestion mémoire, se termine par une question : « Des commentaires ? »

Un compteur que tous les cœurs se disputent

Quand un programme lit un fichier, Linux en garde une copie en mémoire vive, le cache de pages, pour ne pas retourner sur le disque à la lecture suivante. Chaque page de ce cache porte un compteur de références : le nombre de lecteurs en train de s’en servir. Tant qu’il n’est pas à zéro, le noyau ne peut pas libérer la page pour la confier à un autre usage.

Ce compteur a un prix. Chaque lecture l’augmente avant de copier, puis le diminue : deux écritures au même endroit de la mémoire. Or chaque cœur du processeur garde sa copie des données récentes ; quand l’un écrit, les autres doivent jeter la leur. Avec des dizaines de fils d’exécution sur la même page, tous passent leur temps à se repasser ce compteur. Sur le portable de Torvalds, cette seule zone concentre 99,92 % de ces conflits entre cœurs, selon la description d’une version antérieure de la série.

Matthew Wilcox, développeur du noyau, avait signalé le problème en 2024 à partir de la charge d’un client : « de vrais utilisateurs » en souffraient, rappelle Torvalds. Trois tentatives se sont succédé sans aboutir : un premier jet de Torvalds, « cassé » mais qu’il a utilisé un an et demi sur sa machine ; une version reprise par Kiryl Shutsemau en octobre 2025 ; une approche d’Ilya Gladyshev, à sa sixième version, qui garde des « problèmes fondamentaux connus ».

Différer la libération plutôt que compter les lecteurs

La nouvelle série renverse la logique : plutôt que de compter qui lit, elle garantit qu’une page retirée du cache ne sera pas réutilisée tant que les lecteurs en cours n’ont pas fini. Elle s’appuie sur RCU (read-copy-update), un mécanisme du noyau qui laisse les lecteurs avancer sans verrou : celui qui veut libérer une donnée attend une « période de grâce », le temps que chaque cœur soit passé par un point où il ne peut plus la lire. Un lecteur peut alors copier depuis la page sans toucher au compteur.

L’idée avait été évoquée sans être essayée. Wilcox y objectait, rappelle la description, qu’« il semble tout simplement trop risqué d’avoir autant de mémoire en attente de réutilisation ». C’est, reconnaît le texte, « la partie la moins résolue » de la série.

« Sous ma direction » : le rôle déclaré de l’outil

Torvalds raconte qu’en vue du sommet annuel des mainteneurs du noyau, où l’usage des grands modèles de langage (LLM, les IA qui génèrent texte et code) était « l’un des grands thèmes », il a voulu « vraiment résoudre cette affaire » avec leur aide. La description de la branche précise : « Le code, les programmes de test, la revue qui a produit la liste ci-dessus et le premier jet de ce texte ont été faits avec un assistant de programmation fondé sur un LLM (Claude Code), sous ma direction. Les mesures ont été faites sur ma machine. » Les textes accompagnant chaque modification sont, note-t-il, « un peu plus verbeux » que ceux qu’il aurait écrits « sans outil, mais c’est peut-être mieux ainsi ».

Claude Code est un produit d’Anthropic ; les agents qui préparent les articles de L’Octet s’appuient eux aussi sur des modèles de cette entreprise (notre méthode).

Le noyau encadre cet usage. Sa documentation sur les assistants de programmation laisse toute la responsabilité à l’humain : il relit le code, vérifie les licences et signe seul la contribution ; une IA ne doit pas apposer la mention « Signed-off-by », qui engage l’auteur, et une mention « Assisted-by » signale l’outil. Le compilateur GCC tranche autrement : sa politique, modifiée le 29 juillet, écarte toute contribution juridiquement significative contenant du contenu généré par un LLM, sauf pour les tests.

23 fois plus vite, sur un cas d’école

Le chiffre vitrine vient d’un processeur AMD Ryzen Threadripper : avec 64 fils lisant le même fichier, on passe de 13,3 à 304 millions de lectures par seconde, environ 23 fois plus. Torvalds tempère aussitôt : c’est « un cas très artificiel », qui relit en boucle la même petite portion d’une page sur tous les cœurs, « donc tout impact dans la vie réelle sera très, très inférieur ». Ce qu’il en retient : la lecture ne bute plus sur les conflits entre cœurs.

Sur son portable (Intel Core i7-8565U, huit fils), le coût d’une lecture tombe de 2 937-2 975 cycles de processeur à 725-726. Pour un ordinateur ou un serveur, rien ne change pour l’instant : seules les charges où beaucoup de fils lisent le même fichier en cache sont concernées, et la série n’est pas intégrée.

Les défauts, listés par l’auteur lui-même

La description consacre une longue section aux « problèmes connus ». Le premier rejoint l’objection de Wilcox : les pages en attente sont invisibles pour l’allocateur, la partie du noyau qui distribue la mémoire libre. Avec un programme d’essai de Kiryl Shutsemau, sur une machine virtuelle de 2 Go, la mémoire s’est épuisée avec les six premiers correctifs seuls, et le noyau a dû tuer un programme. Deux correctifs de plus règlent ce cas en accélérant la libération au-delà de 1 024 pages en attente sur un cœur ; mais « la limite de 1 024 pages est une supposition », écrit le texte, qui signale aussi une régression pour CMA, le mécanisme qui fournit de grands blocs de mémoire d’un seul tenant à certains périphériques.

Quelques programmes d’essai, une compilation et l’usage quotidien du portable : « c’est tout ce qui a été testé ». Pas encore essayés, entre autres : xfstests (la batterie de tests des systèmes de fichiers), KASAN (le détecteur d’erreurs mémoire du noyau), les machines 32 bits et « toute machine autre que celle-ci ». Cette liste date d’une version à huit correctifs ; selon Torvalds, certains points ont été résolus depuis, d’autres ne sont pas à ses yeux de vrais problèmes, « mais devraient être discutés ».

Un défaut trouvé quatre heures après l’envoi

Quatre heures après le courriel, Kiryl Shutsemau a signalé une situation de concurrence, un défaut qui n’apparaît que lorsque deux opérations s’entrecroisent au mauvais moment. Si, pendant qu’un lecteur prépare sa copie, un autre programme retire la page du cache, écrit de nouvelles données et agrandit le fichier, le lecteur voit la nouvelle taille mais copie depuis l’ancienne page, restée valide grâce au délai de libération : « on peut lire des données qui n’y ont jamais été écrites ». Son correctif de deux lignes revérifiait, après lecture de la taille du fichier, que la page est toujours dans le cache. Torvalds a suggéré de regrouper ces vérifications et reconnu ailleurs de « subtils problèmes d’ordre » avec la taille du fichier, « comme l’a souligné Kiryl » ; Shutsemau a envoyé le 14 octobre une version refaite en ce sens. D’autres ajustements attendront, écrit-il, d’être « d’accord sur le mécanisme central ».

Des objections de fond, et un nouveau porteur

Cet accord n’est pas acquis. Matthew Wilcox trouve les chiffres « évidemment convaincants » et remercie Shutsemau d’avoir trouvé une charge qui « a confirmé [ses] craintes », puis d’y avoir remédié ; mais il « n’aime pas » PG_rcu_free, le drapeau (un bit d’état) qui marque les pages à libération différée, et esquisse une autre piste. Torvalds l’écarte : sa série « fonctionne », et c’est le moment de montrer le code, pas des « on pourrait peut-être faire xyz » en l’air. Pedro Falcato doute du critère qui désigne les pages assez relues pour ce traitement ; il ne pense pas « qu’une solution susceptible de modifier en profondeur le système de mémoire virtuelle en vaille la peine », du moins sans cas d’usage réel où les performances changent nettement, « pas un microbenchmark » (un test minuscule et artificiel) : « d’ici là, ces correctifs semblent plus gênants qu’utiles ». Torvalds lui-même ne croit pas sa branche parfaite « du premier coup » : « Bien sûr que non. »

Il passe la main. En vacances à partir de vendredi, puis pris la semaine suivante par la fenêtre d’intégration (la période où il fusionne les nouveautés de la prochaine version du noyau), il a demandé à Shutsemau de « reprendre toute la série », faute de temps. « Oui, je peux », a répondu celui-ci le 14 octobre. Il propose un drapeau propre aux machines 64 bits, où ces bits sont moins rares ; limiter la fonction au 64 bits paraît « très sensé » à David Hildenbrand. Dans son courriel initial, Torvalds jugeait que les correctifs « n’ont pas l’air mauvais » et que d’autres parties du noyau pourraient profiter de ce report de libération ; c’est désormais Shutsemau qui devra en convaincre ses pairs.

Les citations (Linus Torvalds et sa description de branche, Kiryl Shutsemau, Matthew Wilcox, Pedro Falcato, David Hildenbrand) sont traduites de l’anglais par la rédaction.