Linus Torvalds a posé l'étiquette Linux 7.3-rc1 le dimanche 30 août 2026, refermant une fenêtre de fusion de deux semaines ouverte juste après la sortie de 7.2 le 17 août. Le chiffre marquant, c'est la taille : environ 15 267 commits intégrés, ce que la presse spécialisée place au deuxième rang de l'histoire du noyau derrière la seule version 6.7, et un arbre qui pèse désormais près de 40,98 millions de lignes. Au-delà du comptage, il y a trois changements de performance à anticiper, une série de matériels qui démarrent enfin sans correctifs hors arbre, et une anecdote de débogage qui en dit long sur l'évolution du travail noyau.
The short answer
Linus Torvalds a étiqueté Linux 7.3-rc1 le 30 août 2026. C'est l'une des plus grosses fenêtres de fusion jamais enregistrées en nombre de commits, et le bond du décompte de lignes vient surtout d'un fichier d'en-têtes de registres AMD DCN6 généré automatiquement, pas de logique nouvelle. Trois gains de performance ressortent : les entrées et sorties directes de Btrfs passent d'environ la moitié du débit théorique à environ 95 pour cent, une sonde BMI2 au démarrage retire 71 pour cent du temps de décompression Zstd, et un correctif du MGLRU fait tomber la compilation d'un serveur ARM de 9 248 à 7 861 secondes de temps système. Côté matériel, USB4 et Thunderbolt arrivent pour les Apple M1 à M3, Intel Xe3P avec Nova Lake est activé par défaut, l'activation d'AMD Zen 6 se poursuit, et la manette Steam 2026 reçoit un pilote noyau.
Tous les quelques cycles, quelqu'un remarque que le noyau a franchi un nouveau chiffre rond et en fait une actualité. Cette fois le chiffre rond sera bientôt 41 millions de lignes, et il vaut la peine d'expliquer pourquoi ce nombre ne veut presque rien dire avant d'en venir aux parties de 7.3 qui, elles, comptent.
La taille est réelle, le décompte de lignes n'en est pas la raison
Le nombre de commits est la mesure honnête, et 15 267 est beaucoup. La presse le place au deuxième rang de l'histoire du noyau, derrière la seule 6.7. C'est un vrai signal sur la quantité de travail intégrée en deux semaines.
Le décompte de lignes raconte autre chose. L'arbre a grossi vers 40,98 millions de lignes surtout à cause d'un déversement d'en-têtes de registres pour AMD DCN6, le cœur d'affichage des futures puces graphiques AMD. Ces en-têtes sont générés, ils sont presque intégralement composés de définitions constantes, et personne ne les édite à la main. Phoronix situe désormais le seul pilote graphique noyau d'AMD autour de 6,5 millions de lignes, soit davantage que ce que pesait le noyau entier il n'y a pas si longtemps. Cela dit quelque chose de la surface de programmation d'un processeur graphique moderne, et rien du tout de la complexité du noyau au sens où on l'entend habituellement.
C'est la gestion mémoire qui concentre le travail relisible : environ 1 250 correctifs sur ce cycle contre à peu près 920 sur le précédent.
Trois chiffres à anticiper
Le changement Btrfs est celui qui a le plus de chances de modifier un plan de capacité. Les améliorations du chemin de tampon intermédiaire iomap portent les entrées et sorties directes d'environ 50 pour cent du débit théorique maximal à environ 95 pour cent. Ce n'est pas un réglage, cela arrive avec le noyau. Nous avons décrit le travail sur les E/S directes et fsync de Btrfs au moment de son intégration, et rc1 est le moment où cela devient mesurable de bout en bout plutôt que simplement lisible.
Zstd a reçu le genre de correctif à la fois embarrassant et réjouissant. Le code appelait CPUID à répétition pour tester la présence de BMI2. Or CPUID sérialise le pipeline : chaque appel dans un chemin chaud coûte bien plus que ce que le test rapporte. Linux 7.3 sonde une fois au démarrage et s'en souvient. Le résultat mesuré est 71 pour cent de temps de décompression en moins et 18 pour cent de compression en moins pour crypto_acomp. Volumes Btrfs compressés, swap zram, dépaquetage d'initramfs et images squashfs se trouvent tous en aval.
Troisièmement, un correctif du MGLRU s'est nettement vu sur serveur ARM, faisant tomber le temps système d'une charge de compilation de 9 248 à 7 861 secondes, soit environ 15 pour cent. Cela prolonge le fil de la modification du MGLRU qui a cessé d'évincer les binaires chauds : 7.3 a consacré une part inhabituelle de son budget au comportement de récupération sous pression réelle plutôt qu'à des gains synthétiques.
Du matériel qui n'exige plus de correctifs
C'est le silicium Apple qui franchit l'étape la plus visible. Un premier support USB4 et Thunderbolt arrive pour les M1 à M3, accompagné d'un nouveau pilote Apple PMGR pour la gestion d'énergie. Cela s'appuie directement sur le support de démarrage des M3 Pro, Max et Ultra intégré plus tôt dans ce cycle, et c'est toute la différence entre une machine qui exécute Linux et une machine que l'on peut brancher sur une station d'accueil.
Côté x86, les cartes Intel Xe3P avec Nova Lake sont activées d'emblée plutôt que derrière un indicateur de sondage forcé, une première activation d'Intel Starfire apparaît, et l'on trouve de nouvelles optimisations d'ordonnancement pour les processeurs hybrides ainsi que le support de l'interruption thermique dirigée par boîtier dans le pilote thermique. L'activation des plateformes AMD Zen 6 continue de s'accumuler. Nouveau récupère NVK Vulkan Video. Rust dans le noyau gagne le support PowerPC, ce qui élargit discrètement les terrains où déployer de nouveaux pilotes en Rust. Et oui, la manette Steam 2026 dispose d'un pilote noyau.
Systèmes de fichiers et virtualisation
F2FS a pris 51 commits, ajoutant des sections de queue redimensionnables et des vidages parallèles sur plusieurs périphériques. CephFS change un comportement par défaut qui agace les exploitants depuis des années : les écritures synchrones lorsqu'une grappe approche de la saturation deviennent optionnelles au lieu d'être imposées. KVM intègre une série de 45 correctifs remaniant la conversion de mémoire invitée, par-dessus la scission de kvm_mmu que nous avions détaillée à l'arrivée de la fusion.
Il y a aussi une petite histoire de méthode plutôt que de code. Torvalds s'est servi de Google Gemini pour traquer une régression graphique Intel Xe, décrivant l'outil comme un assistant infatigable tout en notant qu'il a fallu 24 correctifs de débogage et 18 démarrages de noyau pour aboutir. Ce n'est pas une machine qui écrit du code noyau. C'est un mainteneur qui utilise un modèle comme partenaire de bissection patient sur du matériel qu'il ne peut pas reproduire facilement, ce qui est une affirmation nettement moins spectaculaire et nettement plus utile.
Que faire maintenant
Si vous maintenez des noyaux, installez rc1 sur du matériel de réserve, en particulier tout ce qui embarque du silicium Apple, du Nova Lake ou du Zen 6. Ce code d'activation a été testé surtout par ceux qui l'ont écrit, et rc1 est le moment où les démarrages extérieurs trouvent ce qui leur a échappé. Si vous exploitez Btrfs ou si vous vous appuyez sur Zstd côté noyau, construisez dès maintenant un point de mesure face à votre noyau actuel pour que la comparaison d'octobre veuille dire quelque chose.
Si vous portez de la production, ne faites rien pour l'instant. Six semaines de versions candidates servent précisément à cela.
Sources et pour aller plus loin
- Linux 7.3-rc1 With AMD Zen 6 Additions, Better Btrfs Performance and 2026 Steam Controller, Phoronix, 30 août 2026
- Linus Torvalds Announces First Linux Kernel 7.3 Release Candidate, 9to5Linux, 30 août 2026
- Linux Kernel 7.3 RC1 Merge Window Closes With Heavy DRM, Filesystem, and AI-Assisted Debugging, LinuxCompatible, août 2026
- Linux Kernel 7.3-rc1 Released: 41M Lines, Apple Thunderbolt, and KVM Overhaul, Warp2Search, 31 août 2026
Questions fréquentes
Pourquoi le noyau bondit-il vers 41 millions de lignes en une version ?
Presque tout vient d'une seule chose : un déversement d'en-têtes de registres pour AMD DCN6, la génération de cœur d'affichage des futures cartes graphiques AMD. Ces en-têtes sont générés automatiquement, énormes, et composés presque uniquement de définitions constantes : ils gonflent un décompte de lignes sans ajouter quoi que ce soit qu'un humain lise ou maintienne. Phoronix situe le seul pilote graphique noyau d'AMD autour de 6,5 millions de lignes. Si vous cherchez un chiffre qui reflète le changement réel, regardez plutôt le nombre de commits, et 15 267 est effectivement considérable.
Quel est le plus gros gain de performance pour les serveurs ?
Le travail sur les entrées et sorties directes de Btrfs, que la presse chiffre à environ 95 pour cent du débit théorique maximal contre environ 50 pour cent auparavant. Le correctif porte sur le traitement du tampon intermédiaire iomap : ce n'est donc pas une option de montage à activer, c'est un comportement dont vous héritez en montant de version. Si vous exploitez des bases de données ou du stockage objet sur Btrfs et que vous considériez l'écriture directe comme le chemin lent, refaites vos mesures après 7.3 au lieu de supposer que les anciens chiffres tiennent encore.
Qu'est-ce qui change dans Zstd et pourquoi une sonde processeur compte-t-elle ?
Zstd émettait des instructions CPUID à répétition pour tester la présence de BMI2. CPUID sérialise le pipeline : chaque appel dans un chemin chaud coûte donc bien plus cher que le test lui-même. Linux 7.3 sonde une seule fois au démarrage et mémorise la réponse. Le résultat annoncé est 71 pour cent de temps de décompression en moins et 18 pour cent de compression en moins pour crypto_acomp. Tout ce qui s'appuie sur Zstd côté noyau en profite : volumes Btrfs compressés, swap zram, décompression d'initramfs et images squashfs.
Quand Linux 7.3 sortira-t-il réellement ?
Attendez-vous à l'étiquette finale sur la seconde moitié d'octobre 2026, en tablant sur les six ou sept versions candidates habituelles. Torvalds ne s'engage sur aucune date, et une fenêtre de fusion aussi large est exactement le genre de cycle qui s'offre parfois une candidate supplémentaire. Si vous planifiez un rebasage de distribution ou une campagne de qualification noyau, considérez la mi-octobre comme le point réaliste le plus précoce et commencez à tester les candidates dès maintenant sur vos charges réelles.
Vaut-il la peine de tester rc1 sur du vrai matériel ?
Sur du matériel de réserve et en machine virtuelle, oui, et ce cycle plus que d'autres, car une grande partie des nouveautés concerne l'activation de puces qui exigeaient jusqu'ici des correctifs hors arbre. C'est précisément le code qui gagne à être démarré sur des machines que les développeurs ne possèdent pas. Sur quoi que ce soit portant de la production, non. Attendez au moins rc4 et le passage de votre distribution.