L'IA détecte des goulets d'étranglement pouvant accélérer jusqu'à 70 % les compilations de Linux

Un développeur du noyau Linux a utilisé un modèle de langage pour identifier les goulets d'étranglement dans la compilation. Bien que l'outil ait produit un code qu'il a qualifié d'horrible, une révision humaine a permis de préparer 23 correctifs avec des améliorations allant jusqu'à 36 % pour les compilations complètes et 70 % pour les compilations incrémentielles.

• Lorenzo Stoakes a publié une série de 23 correctifs pour accélérer significativement la compilation du noyau Linux.
• Le travail s'attaque aux tâches à un seul fil dans Kbuild, kallsyms, modpost, objtool, mksysmap et le système de compilation Rust.
• Les tests rapportent des améliorations de 36 % pour les compilations avec tous les modules et jusqu'à 70 % pour les compilations incrémentielles.

Une recherche assistée par IA

Un développeur vétéran du noyau Linux a utilisé un modèle de langage de grande taille pour identifier les obstacles qui ralentissent le processus de compilation. Le résultat a été une série de 23 correctifs qui, selon les tests décrits, pourraient accélérer considérablement différentes classes de compilations, bien qu'ils doivent encore passer par le processus de révision avant d'être intégrés au noyau principal.

Lorenzo Stoakes a publié la proposition le 8 septembre 2026 avec un objectif concret : réduire le temps que le système passe à attendre des tâches à un seul fil. L'idée n'est pas de remplacer les développeurs par de l'intelligence artificielle, mais de l'utiliser pour inspecter le processus, identifier les points d'attente et suggérer des modifications qui pourront ensuite être auditées techniquement.

Cependant, l'outil n'a pas fourni un résultat prêt à être intégré au projet. Stoakes a expliqué que le modèle a généré beaucoup de code, une partie considérable duquel il a qualifié d'horrible, ce qui l'a contraint à réviser et à réécrire largement ses propositions avant de les transformer en une série de correctifs cohérents.

Le développeur a également noté que le modèle a aidé à coordonner les exécutions de compilation, les tests, le débogage et l'analyse. Néanmoins, il a affirmé avoir vérifié manuellement la correction tant des compilations que des noyaux en cours d'exécution, en plus de vérifier personnellement les améliorations de performance.

Le problème des tâches à un seul fil

La compilation du noyau combine de nombreuses phases qui peuvent être exécutées sur différents cœurs du processeur, mais certaines tâches restent limitées à un seul fil et créent des points d'attente. Lorsque une étape se termine avant une autre, les ressources disponibles ne peuvent pas toujours être pleinement exploitées, de sorte que la vitesse totale est conditionnée par les segments les moins parallélisés.

Les correctifs de Stoakes tentent de mieux répartir plusieurs de ces opérations afin que plus de travail avance simultanément. L'approche affecte des composants du système de construction tels que Kbuild, kallsyms, modpost, objtool et mksysmap, ainsi que le système utilisé pour compiler le code Rust dans le noyau.

Kbuild coordonne une grande partie du processus de construction, tandis que d'autres outils génèrent des informations, vérifient des objets ou préparent des éléments nécessaires au résultat final. La proposition vise à faire en sorte que ces fonctions travaillent plus efficacement et réduisent les intervalles pendant lesquels une phase attend qu'une autre termine une opération séquentielle.

L'étendue de la série montre également pourquoi détecter des goulets d'étranglement peut être plus important qu'optimiser un seul outil. Une petite amélioration dans plusieurs phases connectées peut produire une économie considérable dans le temps total, en particulier lorsque le système recompte fréquemment le noyau pendant le développement et les tests.

Améliorations rapportées dans différentes compilations

Les résultats cités pour une compilation du noyau avec tous les modules activés indiquent une réduction d'environ 36 % du temps nécessaire. Cette mesure représente le scénario le plus large de la série, car elle inclut un grand nombre de composants et permet d'observer comment les optimisations se comportent lorsque le processus doit construire une configuration étendue.

Les compilations incrémentielles, qui reconstruisent uniquement les parties affectées par des changements récents, pourraient en bénéficier encore davantage. Dans ce cas, les tests mentionnés rapportent des améliorations allant jusqu'à 70 %, une différence significative pour les développeurs qui répètent le cycle de modification de code, de compilation, de test et de réajustement.

Les chiffres ne représentent pas une promesse universelle pour chaque machine ni chaque configuration du noyau, et la proposition elle-même inclut des résultats de référence pour différents scénarios. Sa valeur principale réside dans le fait de montrer que les goulets d'étranglement à un seul fil offrent encore une marge importante pour améliorer l'expérience de compilation.

Audit humain et prochaines étapes

Stoakes a noté la participation du modèle par une étiquette "Assisted-by" dans chaque commit de la série. Il a également indiqué qu'il avait intensément édité les messages de confirmation, la lettre de présentation et les commentaires, une tâche nécessaire pour que d'autres mainteneurs puissent comprendre les décisions techniques et évaluer leurs conséquences.

Cette supervision est particulièrement pertinente dans un projet comme le noyau Linux, où un changement de performance ne peut pas être évalué uniquement par le temps de compilation. Les correctifs doivent préserver la correction du système, éviter les erreurs dans des configurations peu communes et maintenir la stabilité du code qui finit par s'exécuter sur des appareils et des serveurs.

L'expérience expose une tension connue dans l'utilisation de modèles de langage pour l'ingénierie logicielle : ils peuvent explorer rapidement des alternatives et détecter des motifs difficiles à examiner manuellement, mais leurs sorties peuvent contenir des erreurs, des structures défectueuses ou des décisions qui ne respectent pas les normes du projet. Dans ce cas, l'utilité de l'IA est apparue dans la recherche et l'analyse, tandis que la validation finale est restée sous la responsabilité humaine.

L'information a été rapportée par Phoronix, qui a recueilli la publication de Stoakes et les résultats de la série de correctifs. La prochaine étape sera la révision technique par la communauté et les mainteneurs concernés, après quoi le travail pourrait parvenir au noyau principal et accélérer les compilations sur différentes machines et configurations.

Pour l'instant, les chiffres doivent être interprétés comme des résultats d'une proposition en révision et non comme une amélioration déjà disponible pour toutes les distributions Linux. Si les correctifs conservent leurs avantages sans introduire de problèmes de correction, ils pourraient transformer l'une des tâches les plus répétitives du développement du noyau en un processus considérablement moins lent.