Linus Torvalds, créateur de Linux et principal responsable de la supervision du développement du noyau, a utilisé l’outil Claude Code d’Anthropic pour contribuer à résoudre un goulot d’étranglement vieux de plus de deux ans dans le chemin de lecture des fichiers. Une série de 10 correctifs a permis d’améliorer jusqu’à 23 fois le débit de lecture lors d’un test synthétique sur une machine Threadripper à 64 cœurs, mais les réviseurs du noyau Linux ont ensuite découvert une condition de concurrence et soulevé des questions concernant la sûreté de la conception de la récupération de mémoire, ce qui signifie que les correctifs n’ont pas encore été intégrés.
Un problème lié aux compteurs de références de la mémoire des pages
Ce travail concerne une contention sur les compteurs de références d’objets appelés folios au sein du cache de pages, une couche qui conserve les données lues depuis les fichiers afin d’accélérer leur accès. Le goulot d’étranglement a été signalé en 2024 après être apparu dans la charge de travail d’un client, et des tests menés sur l’ordinateur portable de Torvalds ont montré que cette contention représentait 99,92 % des opérations HITM entre les cœurs lors d’un test utilisant huit threads.
Torvalds a déclaré avoir passé 18 mois à utiliser une version défectueuse de sa précédente correction du problème, tandis que d’autres développeurs rencontraient des difficultés dans leurs propres tentatives. Les nouveaux correctifs visent à supprimer les opérations d’incrémentation et de décrémentation des références de folio du chemin de lecture mise en cache le plus utilisé, Torvalds avertissant que les gains seraient nettement inférieurs dans les charges de travail réelles par rapport au test synthétique.
Le rôle de Claude Code et les limites du résultat
Une branche expérimentale nommée noref-filemap-read-with-llm est apparue dans l’arbre de Torvalds, puis la série a inclus une explication du rôle de Claude Code. Selon Torvalds, l’outil a écrit l’implémentation, les tests et la documentation initiale, et a également révisé le code sous sa direction, tandis que lui-même s’est chargé d’exécuter les tests de performance.
La première série a fait passer le débit de lecture sur son ordinateur portable d’environ 10 millions à 33 millions de lectures par seconde, et a réduit le nombre de cycles processeur par lecture d’environ 2 950 à 725. La série révisée a quant à elle fait passer les performances sur une machine Threadripper de 13,3 millions à 304 millions de lectures par seconde sous forte charge, avec une diminution du nombre de cycles par lecture, qui est passé d’environ 20 000 à 735.
Pourquoi les chiffres de performance ne suffisent-ils pas ?
Cette amélioration s’est accompagnée de coûts potentiels. La première implémentation imposait une période d’attente forcée lorsque le processeur dépassait 1 024 pages en attente de récupération. Les lectures vers des pages utilisateur non liées entraînaient également une erreur supplémentaire avant le retour au chemin existant, faisant passer le coût d’une lecture monothread de 16 octets d’environ 4 150 à 6 550 cycles. Il n’est pas encore établi si cette régression subsistera dans la version rcu-free-v3.
La revue a révélé le risque le plus important
Matthew Wilcox s’est opposé à l’utilisation du nouvel indicateur PG_rcu_free et a proposé une solution de remplacement fondée sur le type de page ainsi que sur un mécanisme différent de récupération des folios inactifs. Kiryl Shutsemau a également proposé de limiter l’indicateur aux systèmes 64 bits, une orientation soutenue par David Hildenbrand.
Shutsemau a aussi découvert une condition de concurrence dans la fonction filemap_read_rcu_batch() : le remplacement d’un folio suivi d’un agrandissement de la taille du fichier pourrait exposer des données qui n’ont pas réellement été écrites. Torvalds a proposé de lire la taille du fichier plus tôt et de regrouper les opérations de vérification, ce qui a été intégré à un correctif révisé.
Lecture éditoriale de certi.news : ce cas montre que les outils de programmation fondés sur l’intelligence artificielle peuvent parvenir rapidement à des améliorations importantes lors de tests du noyau, mais qu’ils ne suppriment pas la nécessité d’une revue spécialisée comprenant la concurrence et le cycle de vie de la mémoire. Les chiffres records démontrent ici un gain dans un environnement précis, et non une aptitude automatique à l’intégration ni une garantie de sûreté de l’implémentation.