Linux 7.3-rc2 corrige l’ordonnancement des processeurs hybrides
La version rc2 du noyau Linux 7.3 corrige les erreurs d’ordonnancement cache-aware sur les CPU hybrides et poursuit la migration mémoire vers kmalloc_obj. Testez cette rc2 si vous exploitez des processeurs Intel Core hybrides ou des machines de type big.LITTLE.
6 septembre 2026. Linus Torvalds publie Linux 7.3-rc2, deuxième candidat du cycle qui doit aboutir à la version stable 7.3 dans la seconde moitié d’octobre. La rc2 embarque une correction attendue de l’ordonnanceur pour les CPU hybrides, une migration mémoire à l’échelle de l’arbre vers kmalloc_obj et un changement de sécurité notable autour de RandStruct et de Rust. Pourquoi c’est important : ces trois correctifs touchent directement la performance et la sûreté mémoire du noyau qui équipera vos serveurs à l’automne.
L’ordonnanceur apprend à ne plus piéger les tâches sur les cœurs basse consommation
La correction la plus concrète concerne l’ordonnancement cache-aware sur les CPU hybrides, comme les Intel Core (et Core Ultra). Le mécanisme regroupe les tâches liées sur des cœurs qui partagent le même cache de dernier niveau (LLC) pour améliorer la localité de cache et réduire la latence. Mais sur les puces asymétriques de type big.LITTLE, ce regroupement peut se retourner contre la performance : des tâches lourdes finissaient coincées sur les cœurs E, les petits cœurs basse consommation.
Tim Chen, ingénieur chez Intel, a corrigé ce « misfit ». Son patch interdit la migration LLC quand la tâche tient sur son CPU source mais pas sur le CPU de destination, et veto le rééquilibrage actif dans la même condition. Les deux contrôles sont déclenchés uniquement sur les processeurs hybrides : les systèmes symétriques ne sont pas affectés.
La correction verrouille les deux points d’entrée de la migration cache-aware. La fonction can_migrate_llc_task() refuse la migration LLC quand la tâche tiendrait sur son CPU d’origine mais pas sur le CPU cible, tandis que alb_break_llc() oppose un veto au rééquilibrage actif dans la même situation. Les tâches qui ne tenaient déjà pas sur leur CPU d’origine restent sous la politique LLC existante, ce qui préserve la migration montante vers les gros cœurs.
Le patch ajoute une priorité : quand des tâches misfit sont détectées lors de la classification, leur migration vers un meilleur CPU prime sur l’agrégation LLC. Comme l’explique Tim Chen, « un CPU mieux adapté améliorera la performance plus qu’une meilleure localité de cache ». Concrètement, vos charges CPU-intensives ne devraient plus se retrouver à tourner sur les cœurs économes d’une puce hybride.
Une migration mémoire vers kmalloc_obj, plus sûre et plus propre
La rc2 intègre aussi une conversion à l’échelle de l’arbre menée par Kees Cook : davantage d’appels kmalloc() basculent vers la famille kmalloc_obj(), introduite dans Linux 7.0. Le script Coccinelle a touché des centaines de fichiers et plus de 600 lignes d’allocations.
L’intérêt dépasse l’esthétique. Les fonctions kmalloc_obj() n’exigent plus de sizeof() ni de nom de type : l’allocateur introspecte le type de la variable cible. Cela ouvre la porte à un durcissement type-aware — alignement adapté, ou randomisation d’offset par allocation sans casser les exigences d’alignement. C’est un pas de plus vers un allocateur qui connaît la forme des objets qu’il alloue, et donc vers moins de débordements et de confusions de type.
La conversion illustre le gain d’ergonomie comme le gain de sécurité. Un appel classique kmalloc(sizeof(*p), gfp) devient kmalloc_obj(p, gfp) : la taille est déduite du premier argument, et le retour n’est plus un void * générique mais un pointeur typie vers le type de la cible. Le type peut même être passé explicitement — kmalloc_obj(struct foo, gfp) — et la variable déclarée via __auto_type. Cette introspection rend possible des choix d’alignement informés et un durcissement futur sensible au type, deux leviers que l’ancienne API ne permettait pas.
/* avant : la taille doit être explicitée */
struct foo *p = kmalloc(sizeof(*p), GFP_KERNEL);
/* après : le type est déduit de la cible */
struct foo *p = kmalloc_obj(p, GFP_KERNEL);RandStruct recule par défaut quand Rust est présent
Le troisième signal est un arbitrage de sécurité à surveiller. La rc2 désactive par défaut RandStruct — la randomisation de la disposition des structures de GCC — lorsque le support Rust est présent avec une chaîne de compilation Rust. RandStruct rend les exploits du noyau plus difficiles en cassant les offsets prévisibles ; le voir reculer dans les builds activant Rust signifie que le gain de sûreté mémoire apporté par le code Rust s’accompagne, dans ces configurations, d’un renoncement partiel à la randomisation de structure.
Ce choix est cohérent avec la stratégie long terme du noyau : Rust est présenté comme la réponse structurelle aux failles mémoire, au point que l’activation de RandStruct devient conditionnelle. Reste qu’un administrateur qui compile son propre noyau doit savoir ce qu’il perd et ce qu’il gagne selon qu’il active ou non Rust. La randomisation de structure n’est pas un gadget : elle casse les offsets qu’un exploit doit prédire pour escalader, et son absence dans les builds Rust réduit concrètement la friction d’exploitation de ces configurations.
Un cycle dense, assumé par Torvalds
La rc2 confirme le diagnostic posé en amont. Greg Kroah-Hartman avait prévenu d’un cycle « rough » en raison de l’afflux continu de correctifs générés par IA/LLM. Linus Torvalds, dans son annonce légèrement retardée, le reconnaît : « Ce n’était pas une rc2 particulièrement calme, et pourtant elle l’était clairement. C’est une version rc pleine graisse. » Il cite des correctifs venus de plusieurs systèmes de fichiers, un pull drm conséquent, des correctifs networking et bpf, ainsi que de nombreuses arborescences de pilotes.
Le noyau dépasse désormais 41 millions de lignes de code source. La densité du cycle rend la phase de test d’autant plus précieuse : les régressions découvertes sur 7.3-rc2 sont exactement ce qui doit être remonté avant la stabilisation d’octobre.
Le cycle ne se résume pas à ces correctifs. La vue d’ensemble des fonctionnalités de 7.3 promet un Btrfs plus rapide et un large apport de support matériel, tandis que les premiers benchmarks d’AMD EPYC sur 7.3 laissent entrevoir des gains de performance à l’horizon. La rc2 est donc moins une étape anodine qu’un point de bascule : ce qui s’y corrige déterminera la qualité de la stable d’octobre.
À noter aussi : la rc2 embarque des correctifs d’affichage Nouveau pour les GPU NVIDIA Blackwell et intègre les changements EDAC qui avaient été oubliés lors de la fenêtre de fusion. Ce rappel illustre la densité du cycle — même ce qui n’a pas été absorbé à temps finit par revenir dans le flux de la rc2.
Verdict
Si vous exploitez des serveurs ou postes sur CPU hybrides (Intel Core Ultra, puces big.LITTLE), testez 7.3-rc2 sur un sous-ensemble non critique et validez que vos charges CPU-intensives ne se retrouvent plus sur les cœurs E : la correction de Tim Chen est un gain de performance direct.
Si vous compilez votre propre noyau, revoyez votre configuration RandStruct et Rust : la bascule de défaut change ce que vous activez implicitement, et mérite une décision explicite.
Si vous ne touchez pas au noyau, attendez la stable 7.3 d’octobre, mais notez que la migration kmalloc_obj et la correction d’ordonnancement arrivent sans action de votre part via votre distribution.
Références
- Phoronix — Linux 7.3-rc2 Released Following Another Busy Week, 6 septembre 2026
- Phoronix — Linux 7.3-rc2 Scheduler Fix For Cache Aware Load Scheduling Misfits On Hybrid CPUs, 6 septembre 2026
- Phoronix — Linux 7.3-rc2 Transitions More kmalloc Calls To The Superior kmalloc_obj, 6 septembre 2026
- kernel.org — Linux 7.3-rc2