Linux 7.3 aborde sa fenêtre de merge en candidat LTS et achève sched_ext
La fenêtre de merge de Linux 7.3 s’ouvre mi-août 2026 avec 1 250 patches de gestion mémoire, la finalisation de sched_ext et le support initial d’AMD UALink et des Apple M3. Les administrateurs sous pression mémoire ont deux correctifs concrets — rmap_walk_ksm et zsmalloc — à anticiper avant la sortie prévue en octobre 2026.
1 250 patches. 705 millisecondes. 1 024 accélérateurs. Linux 7.3 est entré dans sa fenêtre de merge à la mi-août 2026, dans la foulée de la sortie de Linux 7.2 le 17 août. Le cycle se présente comme le candidat LTS de l’année, et il tient trois promesses : une gestion mémoire nettement accélérée, un sched_ext désormais complet, et l’ouverture de deux fronts matériels — AMD UALink et les Apple M3. Pour un administrateur, ce qui se joue maintenant n’est pas anecdotique : ce qui entre dans 7.3 restera maintenu des années s’il décroche le statut LTS.
Le candidat LTS qui fige les choix
La fenêtre de merge est le moment où les sous-systèmes posent leurs contributions sur la branche principale de Linus Torvalds, avant les release candidates. Si 7.3 est bien retenu comme Long Term Support, chaque décision prise aujourd’hui aura une durée de vie de plusieurs années — c’est la raison pour laquelle la densité de ce cycle compte double.
Le signal le plus lisible vient du sous-système mémoire : Andrew Morton a expédié une pull request de 1 250 patches pour la gestion mémoire, contre 920 au cycle précédent. C’est une hausse de plus d’un tiers, concentrée sur des optimisations destinées aux charges sous contrainte mémoire — serveurs, Android, zRAM et Zswap. Ce volume inhabituel a d’ailleurs poussé Morton à recourir à Gemini pour rédiger ses résumés de patches, tant le flot était dense.
Deux goulets mémoire guéris
Deux correctifs méritent une attention particulière, parce qu’ils touchent des douleurs que les équipes mesurent en millisecondes.
Le premier est signé ZTE et vise rmap_walk_ksm(). Les ingénieurs ont identifié un défaut de performance sévère : sous pression mémoire, des applications pouvaient se figer plusieurs centaines de millisecondes. Le correctif fait passer le pire temps de tenue de verrou de 705 ms à 1,44 ms en moyenne. Sont directement concernés les runtimes JVM et Go, et les moteurs de base de données comme MySQL et PostgreSQL, qui créent des dizaines de milliers de VMA partageant un unique anon_vma.
Le second est signé Wenchao Hao de Xiaomi et s’attaque à la contention de verrous dans zsmalloc. Le résultat : jusqu’à 1,83× d’accélération sur un Raspberry Pi 4B en charge de désallocation concurrente, et 1,4× sur un système Intel à 20 cœurs. C’est le correctif que les utilisateurs de Zswap et de zRAM — donc la majorité des Android et des serveurs économes en RAM — attendaient.
sched_ext devient complet
sched_ext — le framework qui permet d’écrire des ordonnanceurs en BPF — est déclaré complet dans ce cycle. La nouveauté de fond est la sous-ordonnancement hiérarchique : un ordonnanceur BPF racine peut céder un sous-arbre cgroup à un sous-ordonnanceur imbriqué, avec des concessions de CPU révocables. Les objets arena franchissent désormais la frontière noyau/BPF sous forme de pointeurs typés, et l’exécution de secours des tâches affamées fonctionne sur un budget de bande passante réduit plutôt que d’attendre l’éjection par watchdog.
Pour les équipes qui veulent vérifier que leur noyau embarque le framework, une vérification suffit :
# Vérifier que sched_ext est présent dans la configuration du noyau
grep SCHED_CLASS_EXT /boot/config-$(uname -r) La maturité de sched_ext n’est pas un détail : c’est ce qui permet d’expérimenter un ordonnanceur sur mesure sans recompiler le noyau, puis de l’activer en production quand il a fait ses preuves.
Le matériel qui s’ouvre
Le cycle 7.3 est aussi une grosse livraison matérielle. AMD reçoit une série de 95 patches ajoutant le support d’UALink dans AMDGPU : un standard ouvert capable de connecter jusqu’à 1 024 accélérateurs dans un même domaine, où les GPU accèdent directement à la mémoire distante sans copie — contrairement à RDMA — via un espace d’adressage Network Physical Address dédié. Le premier pilote CXL Type-2 in-tree débarque également pour les cartes réseau AMD Solarflare SFC9100.
Côté Apple, les M3 Pro, M3 Max et M3 Ultra obtiennent un support initial en Device Tree pour le noyau principal — la fondation que le projet Asahi Linux attendait pour avancer, même si l’accélération GPU reste hors périmètre. Rust dans le noyau gagne une architecture de plus avec PowerPC (32 et 64 bits). Et NTFS3 reçoit une refonte de sécurité de 922 lignes sur 21 commits, corrigeant des écritures hors limites, des lectures hors limites et des fuites d’information, tout en ajoutant le support des flux alternatifs (ADS).
L’anecdote qui dit beaucoup : Linus, Gemini et un caractère
Le cycle a livré une histoire qui résume l’état du développement noyau en 2026. Linus Torvalds a lui-même traqué un bug du pilote Intel Xe qui provoquait des écrans noirs sur les GPU Battlemage G21. La cause : une erreur de calcul d’offset VRAM dans get_flat_ccs_offset(), corrigée par un seul caractère — passer de round_up() à round_down(). Il lui aura fallu 24 patches de code de debug et 18 démarrages du noyau, avec Gemini comme « assistant infatigable », dont le commit final a été rédigé par l’IA.
L’anecdote n’est pas qu’un divertissement. Elle croise un débat de fond du cycle : l’afflux de patches générés par IA, qui a selon la communauté noyé le développement ARM64 pendant le cycle 7.2 — aucun vrai feature n’a atterri pour AArch64 à cette période, un vide que 7.3 commence à combler. La question de la qualité des contributions assistées par IA est désormais un sujet de maintenance du noyau, pas un sujet de blog.
Le reste du cycle : fichiers, crypto et calendrier
Le volet systèmes de fichiers n’est pas en reste. ext4 débloque les écritures DIO parallèles quand c’est sûr, et l’optimisation ext4_mb_prefetch() pour fallocate() évite un travail inutile. btrfs abandonne le free space v1 comme valeur par défaut au profit du free space tree v2 — déjà le choix de mkfs depuis le noyau 5.15 — tout en maintenant la compatibilité des systèmes existants.
Côté crypto, un nouveau sysctl af_alg_restrict assorti d’une liste blanche permet aux administrateurs de restreindre les algorithmes exposés par l’interface AF_ALG aux programmes utilisateur. C’est un durcissement ciblé de surface : on ferme une porte d’accès à la crypto noyau plutôt que de la laisser grande ouverte.
Le calendrier reste le point de repère : Linux 7.3 est attendu autour d’octobre 2026, avec un premier release candidate dans les semaines qui viennent. D’ici là, les correctifs mémoire descendront progressivement dans les branches stable — ce qui signifie que la valeur de ce cycle ne se limite pas à ceux qui adopteront la version majeure dès sa sortie.
Verdict
Si vous exploitez des serveurs ou des hôtes sous pression mémoire — Zswap, zRAM, bases de données, runtimes JVM ou Go — préparez la migration vers Linux 7.3 dès sa sortie prévue en octobre 2026 : les correctifs rmap_walk_ksm() et zsmalloc se traduisent par des latences de queue mesurablement réduites, et le statut LTS probable garantit leur maintien sur le long terme.
Si votre parc est hétérogène ou figé sur une branche stable plus ancienne, ne forcez pas : les correctifs mémoire descendront dans les branches stables, mais le bénéfice complet de sched_ext et du support UALink n’a de sens que pour ceux qui peuvent adopter la version majeure. Pour le reste, surveillez simplement que la version que vous retenez récupère les deux correctifs mémoire — c’est eux qui paieront le plus vite.
Références
- Linux Kernel 7.3: What’s New in the Upcoming Kernel Release — Linux Compatible, août 2026
- Kernel coverage — LWN.net, consulté le 27 août 2026