Intel a placé dans l'arbre tip une série de correctifs d'ordonnancement, visant la fenêtre de fusion de Linux 7.3, qui réparent l'équilibrage de charge par cluster sur les processeurs hybrides. En résumé : l'ordonnancement par cluster, une fonction de 2021 censée répartir le travail entre les clusters partageant un cache L2, fait le bon choix sur les machines uniformes et le mauvais sur les puces qui mêlent cœurs de performance et cœurs d'efficacité. Ricardo Neri, ingénieur Intel, travaille le sujet, et ses tests couvrent Alder Lake, Lunar Lake et Panther Lake dans plusieurs configurations SMT. Aucun chiffre de performance n'a été publié. Nous avons regardé ce que l'ordonnanceur ratait vraiment.
The short answer
Ricardo Neri, ingénieur Intel, a placé en attente des correctifs qui réparent l'équilibrage de charge par cluster sur les processeurs hybrides. L'ordonnancement par cluster répartit les tâches entre les clusters partageant un cache L2, ce qui est le bon réflexe sur une machine uniforme. Sur les puces hybrides il se trompe : les tâches inadaptées rejoignent bien les cœurs de performance, mais les tâches restantes qui se posent sur les cœurs d'efficacité ne se répartissent pas uniformément entre les clusters de ces petits cœurs. Le correctif vise la fenêtre de fusion de Linux 7.3 et a été validé sur Alder Lake, Lunar Lake et Panther Lake dans plusieurs configurations SMT. Aucun chiffre n'a été publié, Neri prévoit de mesurer sur Core Ultra pendant le cycle.
Les correctifs d'ordonnancement font rarement une lecture passionnante, et la plupart méritent cette réputation. Celui-ci vaut dix minutes parce qu'il illustre proprement un mode de défaillance récurrent dans le noyau : deux mécanismes corrects chacun de son côté, écrits à des années d'écart, qui se rencontrent sur un matériel qu'aucun des deux n'avait en tête.
Ce que l'ordonnancement par cluster devait faire
Un processeur moderne ne présente pas une liste plate de cœurs. Les cœurs sont groupés, et le groupement qui compte ici est le cluster : un ensemble de cœurs qui partagent des ressources intermédiaires, typiquement un cache L2. Linux modélise cela comme un domaine d'ordonnancement, activé par CONFIG_SCHED_CLUSTER, ajouté en 2021.
La politique s'énonce simplement. Quand la machine n'est que partiellement occupée, répartir les tâches exécutables entre les clusters plutôt que les entasser dans un seul. Deux tâches dans deux clusters différents disposent chacune d'une part entière de capacité et de bande passante L2. Deux tâches dans le même cluster se les partagent, et sur tout ce qui touche à la mémoire avec un peu d'enthousiasme, cela se voit.
Le choix inverse, le regroupement, n'est pas faux en général. C'est ce que vous voulez quand la consommation compte plus que le débit, car un cluster sans rien dessus peut descendre dans un état de veille plus profond. Linux choisit la répartition pour les systèmes partiellement chargés parce que la contention de cache coûte en général plus que la veille ne rapporte.
Sur une machine uniforme, où chaque cœur a la même capacité maximale, ce raisonnement tient.
Là où cela déraille
Ajoutez maintenant la capacité asymétrique. Une puce hybride Intel possède des cœurs de performance, généralement avec SMT, et des cœurs d'efficacité disposés en clusters. L'ordonnanceur dispose d'un mécanisme distinct pour cela, construit autour de la notion de tâche inadaptée : celle dont la demande dépasse ce qu'un petit cœur peut fournir, et qu'il faut donc déplacer vers un gros.
Sur un système partiellement occupé, avec des processeurs inactifs et environ une tâche par processeur occupé, le résultat attendu tient en deux étapes. Les tâches inadaptées vont sur les cœurs de performance. Tout le reste s'exécute sur les cœurs d'efficacité et, l'ordonnancement par cluster étant actif, ces restes doivent se répartir uniformément entre les clusters de cœurs d'efficacité.
L'étape une fonctionne. L'étape deux non. Sur plusieurs générations hybrides Intel déjà sur le terrain, et sur des puces à venir, les tâches restantes ne se distribuent pas entre les clusters de petits cœurs comme la conception le prévoit. Elles se concentrent, partagent le L2 entre elles, pendant que d'autres clusters restent inactifs à côté. C'est exactement le résultat que l'ordonnancement par cluster existe pour éviter, atteint par l'interaction de deux fonctions écrites chacune en supposant l'autre absente.
La série de Neri est en attente dans la branche sched core de l'arbre tip et devrait être fusionnée pendant la fenêtre Linux 7.3. Ses tests couvrent Alder Lake, Lunar Lake et Panther Lake, SMT activé et désactivé, ce qui est la bonne matrice pour ce genre de changement puisque le SMT modifie la façon dont le niveau des frères et sœurs interagit avec tout ce qui se trouve au-dessus.
Ce que vous pouvez mesurer aujourd'hui
Il n'y a rien à configurer et aucun bouton à tourner. Ce que vous pouvez faire, à peu de frais, c'est connaître la topologie sur laquelle vous tournez, pour qu'une future montée de noyau explique une variation observée ou s'en disculpe.
Les masques de cluster vivent dans sysfs. Sur une machine dont le noyau intègre l'ordonnancement par cluster, chaque processeur expose ses frères de cluster, et comparer cela au plan des types de cœurs vous dit combien de clusters de petits cœurs vous avez réellement. Sur une puce hybride de portable, vous trouverez en général des cœurs d'efficacité par groupes de quatre partageant un L2, et des cœurs de performance présentés comme leur propre groupe avec des frères SMT en dessous.
Deux choses valent la peine d'être capturées avant une mise à jour. D'abord, savoir si CONFIG_SCHED_CLUSTER est actif dans votre noyau courant, car un noyau de distribution sans cette option ne sera concerné par rien de tout cela. Ensuite, une mesure de référence de la charge qui vous intéresse, prise à charge partielle et non à saturation. Le défaut n'existe que lorsqu'il y a un meilleur endroit où poser une tâche, donc un test qui sature tous les cœurs ne vous apprendra rien.
Ce qu'il faut en attendre
La réponse simple est que personne ne connaît encore l'ampleur, et prétendre le contraire serait malhonnête. Aucun chiffre n'accompagne la série, et Neri a annoncé son intention de mesurer sur du matériel Core Ultra pendant le cycle 7.3.
Ce qui est prévisible, c'est la forme. Les charges qui tombent dans la fenêtre du défaut sont celles qui font tourner plusieurs fils indépendants et moyennement gourmands en cache sur une machine occupée mais pas pleine. Un serveur de compilation entre deux pics. Un hôte de conteneurs à mi-capacité. Un poste de travail qui compile en arrière-plan pendant qu'on travaille au premier plan. Ces situations sont assez courantes pour qu'un correctif de justesse vaille le coup même si le gain moyen se révèle modeste.
Les charges qui ne verront rien sont les deux extrêmes : un fil unique sur un cœur de performance, et une machine à cent pour cent où il ne reste aucun cluster libre.
Pour qui exploite des parcs de machines hybrides ou de petits serveurs hybrides, la bonne posture est de traiter cela comme une correction de justesse plutôt que comme une livraison de performance. Notez votre topologie maintenant, gardez la référence, et lisez les mesures quand elles arriveront plutôt que le résumé du correctif.
Sources et pour aller plus loin
- Linux 7.3 To Better Handle Cluster Load Balancing On Intel Hybrid CPUs, Phoronix, 8 août 2026
- Intel Readies New Linux Patches For Optimized Hybrid CPU Performance, Wccftech
- Enable Cluster Scheduling for x86 Hybrid CPUs, LWN.net
- Hybrid scheduling gets more complicated, LWN.net
- Linux Intel Hybrid Scheduling, Brown et Neri, Linux Plumbers Conference 2022
Questions fréquentes
Qu'est-ce que l'ordonnancement par cluster et pourquoi a-t-il été ajouté à Linux ?
L'ordonnancement par cluster est un domaine d'ordonnancement situé entre le niveau SMT et le niveau du boîtier complet, et il existe parce que les processeurs modernes regroupent les cœurs en clusters qui partagent des ressources intermédiaires, le plus souvent un cache L2. Quand le noyau est compilé avec CONFIG_SCHED_CLUSTER, l'équilibreur de charge connaît ce regroupement et peut décider si deux tâches exécutables doivent se retrouver dans le même cluster ou dans deux clusters différents. Ajouté en 2021, le comportement par défaut est de répartir les tâches entre clusters quand la machine n'est que partiellement occupée, parce que deux tâches dans des clusters séparés disposent chacune d'une part entière de capacité et de bande passante L2 au lieu de se les disputer. Regrouper les tâches dans un seul cluster est le choix inverse, parfois pertinent, surtout pour la consommation, puisque laisser des clusters entiers inactifs leur permet de descendre dans des états de veille plus profonds. Le noyau privilégie la répartition par défaut sur les systèmes partiellement chargés parce que la pression sur le cache coûte en général plus cher que l'économie d'énergie gagnée.
Qu'est-ce qui était cassé exactement sur les processeurs hybrides ?
Le défaut apparaît sur un système partiellement occupé, c'est-à-dire un système où certains processeurs sont inactifs et où les occupés portent à peu près une tâche chacun. Sur une machine à capacité asymétrique, l'ordonnanceur doit d'abord s'assurer que les tâches inadaptées, celles trop exigeantes pour un petit cœur, atterrissent sur les gros cœurs. Cette partie fonctionne. Tout le reste doit se poser sur les petits cœurs, et quand l'ordonnancement par cluster est actif, ces tâches restantes doivent se répartir uniformément entre les clusters de cœurs d'efficacité plutôt que s'entasser dans un seul. C'est cette seconde moitié qui casse. Les deux mécanismes, la gestion de la capacité asymétrique et la répartition par cluster, ont chacun été écrits sans l'autre, et leur interaction sur une topologie qui mêle cœurs de performance avec SMT et clusters de cœurs d'efficacité n'a jamais vraiment été tranchée. Résultat : sur plusieurs générations de puces hybrides Intel déjà livrées, et sur celles à venir, les tâches restantes ne se distribuent pas comme prévu.
Quels processeurs sont concernés, et ai-je quelque chose à faire ?
Les conceptions hybrides d'Intel, celles qui combinent cœurs de performance et cœurs d'efficacité en clusters. Ricardo Neri a validé le travail sur Alder Lake, Lunar Lake et Panther Lake, avec différentes configurations SMT, et la description de la série note que le problème touche plusieurs générations déjà livrées ainsi que des générations futures. Rien n'est demandé à l'exploitant. Il s'agit d'un correctif côté noyau, sans réglage à basculer ni configuration à modifier, et s'il est fusionné dans la fenêtre 7.3 il arrivera sur vos machines quand votre distribution livrera ce noyau. La seule chose utile est de connaître votre topologie avant et après, pour pouvoir expliquer une différence mesurée plutôt que la deviner. Lire les masques de cluster dans sysfs prend quelques secondes, c'est décrit plus bas.
Quel gain de performance faut-il attendre ?
Personne n'a publié de chiffre, et c'est la réponse honnête aujourd'hui. Les correctifs sont en attente dans la branche sched core de l'arbre tip plutôt que fusionnés dans la branche principale, et Neri a indiqué qu'il comptait mesurer sur du matériel Intel Core Ultra pendant le cycle 7.3. Ce sur quoi vous pouvez raisonner, c'est la forme de l'effet plutôt que son ampleur. Les charges les plus susceptibles de voir une différence sont celles qui correspondent aux conditions du défaut : une machine partiellement chargée exécutant plusieurs tâches indépendantes et moyennement gourmandes en cache, ce qui décrit assez bien un serveur de compilation entre deux pics, un portable qui compile en arrière-plan, ou un hôte de conteneurs non saturé. Une machine à pleine charge verra beaucoup moins, car quand tous les cœurs travaillent il n'y a plus rien à répartir. Si votre charge est un seul fil d'exécution sur un gros cœur, cela ne change rien.
Pourquoi l'ordonnancement sur puces hybrides est-il si durablement difficile ?
Parce que l'ordonnanceur doit satisfaire plusieurs objectifs réellement contradictoires avec une information qu'il ne possède qu'en partie. Il veut du débit, ce qui plaide pour répartir le travail entre domaines de cache. Il veut peu de consommation, ce qui plaide pour regrouper le travail et laisser dormir des clusters. Il veut peu de latence pour les tâches interactives, ce qui plaide pour les garder près d'un cœur rapide. Et il doit deviner l'exigence d'une tâche à partir de son historique récent, un signal en retard précisément sur les charges qui changent le plus vite de comportement. Sur une machine uniforme, ces arbitrages sont déjà délicats. Ajoutez des cœurs de capacité maximale différente, certains avec SMT et d'autres non, groupés en clusters qui partagent le cache de façon inégale, et chaque mécanisme écrit pour le cas uniforme doit être revisité pour vérifier ce qu'il suppose désormais. L'ordonnancement hybride dans Linux est une suite pluriannuelle de corrections de ce type, et celle-ci poursuit la série plutôt qu'elle ne la termine.