Un correctif Linux 7.4 ouvre les fichiers 39% plus vite

Un petit correctif du noyau Linux, prévu pour la version 7.4, a augmenté de 39% le débit d'ouverture de fichiers dans le test de son auteur. Mateusz Guzik a envoyé la modification à la liste de diffusion linux-fsdevel le 3 août 2026, après plus de deux ans de révisions. L'enjeu est réel, car ouvrir des fichiers fait partie des opérations les plus fréquentes d'un serveur chargé, et ce gain ne coûte rien en échange.

Le correctif s'intitule "fs: avoid spurious dentry ref/unref cycle on open". Il touche le système de fichiers virtuel, la couche du noyau située au-dessus de chaque système de fichiers et qui traite les requêtes comme open et read.

Ce que change le correctif

Un dentry est l'enregistrement mis en cache par le noyau pour une entrée de répertoire. Il relie un nom dans un chemin au fichier que ce nom désigne. Le noyau compte combien de ses parties utilisent chaque dentry, afin de savoir quand l'enregistrement peut être libéré. Ce décompte est un compteur de références.

Le message de commit de Guzik décrit clairement le gaspillage. L'ouverture d'un fichier prend une référence sur le dernier dentry dans __legitimize_path(). Elle en prend ensuite une deuxième dans do_dentry_open(). Elle relâche enfin la première dans terminate_walk().

Deux de ces trois opérations n'apportent rien. Le correctif laisse do_dentry_open() consommer la référence que le noyau détient déjà, au lieu d'en prendre une nouvelle et de libérer l'ancienne.

La modification est petite. Le diff de la version 5 ajoute 43 lignes et en retire 4, réparties sur trois fichiers : fs/internal.h, fs/namei.c et fs/open.c. Guzik la présente comme une solution plus simple qu'un ensemble de correctifs plus lourd proposé par Al Viro, mainteneur de longue date de ce code.

Le comptage de références semble bon marché isolément. Il ne l'est pas quand de nombreux cœurs touchent le même compteur en même temps. Chaque mise à jour doit devenir visible pour tous les autres cœurs, qui finissent par faire la queue les uns derrière les autres.

Le test derrière les 39%

Le chiffre vient de will-it-scale, une suite qui mesure la tenue des opérations du noyau à mesure que le nombre de cœurs augmente. Guzik a utilisé son cas openro3.c, qui ouvre et ferme le même fichier en lecture seule dans une boucle.

Sur une machine virtuelle à 20 cœurs, les résultats ont évolué ainsi.

Mesure	Opérations par seconde
Avant le correctif	4 043 375
Après le correctif	5 629 378

C'est de là que vient le chiffre de 39%. Phoronix, qui a signalé le correctif le 19 septembre 2026, note qu'il attend dans la branche vfs-7.4.lookup de l'arbre git du VFS, en vue de la fenêtre de fusion de Linux 7.4.

Ce que cela signifie pour les développeurs

Lisez ce test pour ce qu'il est. Dans le cas openro3, chaque cœur ouvre un même fichier partagé, en lecture seule, dans une boucle serrée. Cela maximise la contention sur le compteur exact que ce correctif cesse de toucher, ce qui explique l'ampleur du gain. C'est un plafond, pas une prévision pour votre charge de travail.

Votre gain dépendra du temps que vous passez à ouvrir des fichiers et du nombre de cœurs qui le font en même temps. Trois charges de travail se rapprochent du test. Les systèmes de compilation interrogent et ouvrent des milliers d'en-têtes. Les serveurs web ouvrent les mêmes fichiers statiques à chaque requête. Les outils d'images de conteneurs et de paquets parcourent de grandes arborescences. Les scripts monofils sur un ordinateur portable ne verront presque rien.

Vous pouvez mesurer votre exposition avant l'arrivée du noyau. Comptez les appels système open et openat sur une exécution représentative avec strace -c ou un profil perf, puis comparez au temps total. Si les ouvertures sont négligeables dans votre profil, ce correctif n'est pas votre goulot d'étranglement, quoi qu'en dise le titre.

Ne planifiez pas encore sur une date. Le correctif attend dans une branche de sous-système : il est accepté par ce mainteneur, mais pas encore fusionné dans le noyau principal. Phoronix évoque l'espoir d'atteindre les noyaux stables avant la fin de 2026. Une fenêtre de fusion peut modifier cet ordre, et le code doit ensuite vous parvenir par un noyau de distribution, ce qui ajoute souvent des mois.

La leçon générale est la plus utile. Il s'agit d'une modification de 43 lignes sur un chemin parcouru des milliards de fois par jour depuis des décennies, et il contenait encore deux opérations atomiques redondantes. Les chemins critiques d'un code mûr méritent d'être relus. La série de gains progressifs du noyau se poursuit d'ailleurs : dans le même cycle 7.4, des correctifs kbuild ont réduit les temps de compilation du noyau.