Une branche qui dit qui l’a écrite
Une branche nommée noref-filemap-read-with-llm est apparue le week-end dernier dans l’arbre du noyau de Linus Torvalds lui-même. Elle contient huit correctifs, tous écrits et validés par Torvalds les 9 et 10 octobre, au-dessus de 7.3-rc6. Le dernier est un commit vide qui ne porte que l’explication, et vers la fin de ce texte, sous un intertitre “Tools”, figure un paragraphe que peu de commits du noyau contiennent :
“Le code, les programmes de test, la relecture derrière la liste ci-dessus et le premier jet de ce texte ont été faits avec un assistant de codage à base de LLM (Claude Code) sous ma direction. Les mesures ont été exécutées sur ma machine.”
Phoronix, qui a trouvé la branche en attendant la 7.3-rc7, a relevé que Torvalds ne garde presque jamais de branches de travail dans son dépôt principal. Les huit commits ne sont pas dans master, et il n’a pas dit s’ils entreraient dans la fenêtre de fusion de la 7.4.
Le problème tient à une ligne de cache
La série s’attaque à un problème de contention que Matthew Wilcox avait soulevé en 2024 à partir de la charge de travail d’un client. Quand de nombreux fils lisent de petites quantités dans le même fichier, chaque lecture prend puis relâche une référence sur le folio qui porte la page, si bien que chacune écrit deux fois la même ligne de cache de struct page. Sur le portable de Torvalds — un i7-8565U à quatre cœurs et huit fils — huit fils effectuant des appels pread() de 16 octets sur une seule page concentrent 99,92 % des load HITMs sur cette ligne.
Sa solution consiste à ne plus prendre la référence du tout. Un folio retiré du cache de pages ne revient désormais à l’allocateur qu’après une période de grâce RCU, ce qui veut dire qu’une page trouvée sous rcu_read_lock() contient encore les données du fichier jusqu’à la libération du verrou. La lecture copie alors directement dans le tampon utilisateur, défauts de page désactivés : pas de référence, pas de tampon intermédiaire sur la pile, pas de vérification après la copie et pas de limite de taille.
Les tentatives précédentes, écrit Torvalds, copiaient sans référence dans un tampon de pile puis validaient après coup, et “se sont arrêtées à ce que la validation ne peut pas voir” : libération, réutilisation et réinsertion au même index, migration, et lecture de mémoire qui n’est plus du tout du cache de pages, dont secretmem, la mémoire non acceptée et “ou pire encore du MMIO avec des effets de lecture indésirables”. Différer la libération supprime ces cas au lieu de les détecter.
Trois fois plus de lectures, et 30 538 HITMs ramenés à 101
Les chiffres du message de commit viennent d’une seule machine, sous ext4, avec les mitigations CPU et CONFIG_HARDENED_USERCOPY désactivés. Avec huit fils lisant 16 octets dans une page, le noyau de base atteint 9,9 à 10,4 millions de lectures par seconde à 2 937–2 975 cycles noyau par lecture. Avec la série, il atteint 30 à 33 millions à 725–726 cycles. Quatre fils, un par cœur, passent de 8,9–11,6 millions à 25–26 millions. Les load HITMs mesurés avec perf c2c tombent de 30 538 à 101.
Le coût, c’est la mémoire qui patiente en file en attendant une période de grâce, et c’est la partie que Torvalds qualifie de moins résolue. L’objection de Wilcox à ce report, citée dans le message, était qu‘“il semble tout simplement trop risqué d’avoir autant de mémoire en attente de réutilisation”. Les correctifs 7 et 8 existent pour contenir cela : au-delà de 1 024 pages en attente sur un CPU, un second élément de travail appelle synchronize_rcu_expedited() et libère la liste, ce qui, avec quatre processus perforant des fichiers, survient 4 600 fois par seconde — alors que la documentation de cette fonction dit de ne pas l’appeler en boucle. Torvalds le signale lui-même : “Y a-t-il un moyen d’obtenir une période de grâce courte sans elles ?”
Ce qu’il dit ne pas avoir testé
Le message se termine par la liste de ce contre quoi la série n’a pas tourné : une pression mémoire au-delà d’un seul cas de reproduction en machine virtuelle, lockdep, KASAN, un noyau compilé avec clang, le 32 bits, CONFIG_HARDENED_USERCOPY, et “n’importe quelle machine sauf celle-ci”. Sur la modification de l’ordonnanceur au correctif 8, il écrit : “Je ne suis pas sûr que ce soit la bonne direction ; je préférerais que la tâche qui libère fasse quelque chose de synchrone qui laisse l’ordonnanceur tranquille.”
C’est cette partie qu’il faut suivre, plus que l’outil. Torvalds a publié une série de gestion mémoire critique pour les performances, attribué le code à un assistant, gardé les mesures pour lui et laissé deux questions ouvertes aux mainteneurs des sous-systèmes. Qu’elle survive à la relecture sur la liste de diffusion est un test différent de sa vitesse sur son portable.
