Les correctifs kbuild de Linux 7.4 accélèrent la compilation

Une série de correctifs qui accélère la compilation du noyau Linux a atteint sa troisième version le 18 septembre 2026, et vise désormais Linux 7.4. L'ingénieur d'Arm Lorenzo Stoakes l'a écrite après avoir utilisé un grand modèle de langage pour repérer où la compilation perd du temps. Le résultat mesuré est une compilation qui attend bien moins souvent un seul cœur pendant que les autres restent inactifs.

Le problème visé par la série est énoncé clairement dans la lettre d'accompagnement : une compilation typique du noyau passe un temps frustrant coincée dans des goulets à un seul fil d'exécution. Les machines actuelles ont beaucoup de cœurs. La compilation du noyau confiait pourtant plusieurs de ses étapes à un seul d'entre eux.

Où passait le temps

Le travail touche les parties de la compilation que la plupart des développeurs ne regardent jamais. Kbuild est le système fondé sur make qui pilote l'ensemble. Kallsyms construit la table qui associe les adresses du noyau aux noms de symboles. Modpost vérifie les métadonnées des modules, objtool valide le code généré, et mksysmap écrit la carte des symboles. Le chemin de compilation Rust a également été modifié.

Une partie du gaspillage tenait au volume. La lettre note qu'un noyau x86-64 actuel contient environ 158 000 symboles, si bien qu'un parcours effectue des millions d'itérations. Elle pointe aussi 5 810 entrées d'information de module inutiles pour une compilation x86 defconfig, et 15 200 pour arm64. Un fichier assembleur généré atteignait 37 Mio et demandait 0,57 seconde d'assemblage, deux à trois fois par compilation.

Les chiffres, et leurs écarts

Mesure	Avant	Après
Compilation à vide x86 allmodconfig	11,6s	2,4s
Compilation à vide x86 allmodconfig, autre configuration	11,0s	1,9s
Compilation propre x86 allmodconfig	342,1s	304,5s
Compression kallsyms avec CONFIG_KALLSYMS_ALL	0,59s	0,33s

Ces chiffres viennent de la série publiée, qui comptait 23 correctifs quand Stoakes l'a envoyée le 8 septembre 2026. La troisième version rapportée par Phoronix le 18 septembre en compte 20, rebasée sur le code amont actuel, avec des résultats obtenus sur AMD EPYC, Threadripper et Apple M2. Phoronix situe le gain à vide sur Apple M2 entre 74 et 76 pour cent, et qualifie le résultat de "dans le même ordre de grandeur que les chiffres AMD x86_64".

Les pourcentages mis en avant diffèrent entre les deux comptes rendus. La couverture de Phoronix du 8 septembre décrivait les compilations complètes avec tous les modules comme environ 36 % plus rapides, les compilations incrémentales jusqu'à 70 % plus rapides, et les compilations à vide environ 90 % plus rapides. La série elle-même annonce 79 à 82 pour cent pour les compilations à vide et 11 % pour une compilation allmodconfig propre. L'écart reflète des machines, des configurations et des versions différentes. Prenez donc la fourchette comme la réponse honnête, plutôt qu'un chiffre unique. Notre article sur le lot de noyaux stables à 9 000 correctifs montrait l'autre face du même arbre : beaucoup de code qui bouge, souvent.

Un LLM l'a trouvé, un humain l'a livré

Stoakes a été direct sur la façon dont ce travail a été produit. "Un LLM a été utilisé d'abord pour déterminer où étaient les goulets, puis pour trouver comment les améliorer", a-t-il écrit. Son jugement sur le résultat est moins flatteur : "Il a généré beaucoup de code, en grande partie affreux." Il indique avoir audité et réécrit une bonne part, et fortement retravaillé les messages de commit. Chaque commit porte une mention "Assisted-by" qui nomme cette assistance.

La série précise aussi que la sortie générée a été vérifiée identique octet par octet à celle de l'ancien code. C'est le contrôle qui compte pour un système de compilation, car une compilation plus rapide qui produit un noyau différent n'est pas une compilation plus rapide.

Ce que cela signifie pour les développeurs

Si vous compilez des noyaux régulièrement, c'est le cas à vide qui compte. C'est la compilation lancée après avoir changé un fichier, ou après n'avoir rien changé, et c'est là que la série revendique ses plus grands gains. Ces minutes tombent à chaque itération d'une boucle de débogage.

Attendez l'intégration plutôt que d'appliquer la série maintenant. Elle vise Linux 7.4, et un rebase sur votre arbre sera un meilleur usage de votre temps une fois l'ensemble fusionné. Si vous maintenez une CI qui compile des noyaux, notez que le gain sur la compilation allmodconfig propre est le plus faible, autour de 11 %.

Le récit du procédé mérite aussi l'attention. Une optimisation suggérée par la machine est passée par une relecture humaine, une vérification octet par octet et une mention explicite. C'est cette combinaison qui rend un tel correctif relisible.