Comme le signale Phoronix, l’ingénieur Ricardo Neri (travaillant chez Intel) a proposé plusieurs patchs pour RFC (Request for comment).
Ces patchs interviennent notamment sur les valeurs IPC (instruction-per-cycle). Comme l’explique Neri, les architectures hybrides – qui embarquent des cœurs basse consommation et d’autres taillés pour les calculs plus intensifs – répartissent la charge en fonction des opérations à traiter. Selon les cœurs où elles sont envoyées, les capacités IPC varient.
Les processeurs Intel des générations Alder Lake, Raptor Lake et la future Gen Meteor donneraient alors de meilleures performances sous Linux. L’ordonnanceur (Thread Director chez Intel) pourrait alors « découvrir » l’utilisation d’instructions avancées et s’adresser alors aux cœurs ayant une plus grande valeur IPC.
« Ces patchs introduisent le concept de classes de tâches, proposent des interfaces dont le matériel a besoin pour les implémenter et des changements dans l’équilibreur de charge pour tirer parti de ces informations supplémentaires, en combinaison avec le packing asymétrique », explique l’ingénieur.
Commentaires (14)
#1
Ce serait une nouveauté bienvenue. Dans Linux 4.16 il y avait un patch pour l’intel threat director mais depuis la mise à jour, ma batterie fond comme neige au soleil et tenait bien plus longtemps sans Intel threat director.
J’en avais conclus que Linux n’était pas encore fait pour les pc portables 12th gen.
#1.1
En même temps le noyau 4.16 date de 2018, pas étonnant qu’il y ait des soucis avec le matériel récent (oui, je connais l’existence des backports, ça ne résout pas tout)
La version stable actuelle c’est la 6.0, et la LTS, la 5.15.
#1.2
Je pense m’être planté dans la version citée, c’était peut être la 5.16 pour le coup, à vérifier.
#1.3
Ça semblerait déjà plus logique effectivement 😅
#2
Petite erreur dans la news : ce n’est plus une RFC mais déjà un patch.
#3
Il y a eu un test Phoronix de différents noyaux sur un des derniers Intel … on voit bien que la gestion des runqueue sur les dernières versions ne permettent pas aux procs de sortir leur trippes.
Ceci dit, avec un proc hybride x86 … il va falloir ajouter de l’intelligence dans la gestion des threads. Plus de complexité, plus de code, moins de perfs à priori. J’me d’mande si l’idée des procs hybrides x86, c’est l’idée du siècle.
Il y a bien des trucs côté ARM, mais bon, perso, je ne sais pas si les archi hybrides ARM sont utilisées efficacement aujourd’hui.
#3.1
Côté ARM, ca fonctionne déjà sur une multitude de téléphone Android.
#3.2
Les puces Apple Silicon ont aussi des coeurs de différent type, non ? Donc les Mac M1, M2, M3 …
#3.3
Oui, je sais, mais la question est de savoir si c’est un peu optimisé, beaucoup ou pas du tout.
#4
En fait je me dis que ce qu’il manque aujourd’hui, c’est effectivement une vraie intelligence pour savoir ce qu’il faut mettre sur les cœurs basse conso ou non. J’aurais tendance à penser que sur Linux, beaucoup trop de choses vont sur les cœurs de perf et donc la batterie ne tiens pas longtemps.
Je pense que l’idée est bonne mais il manque clairement de l’optimisation pour que ce soir bien.
#5
#6
C’est bien déployé sur ARM mais nouveau sur x64/86
#7
Ça ne serait pas plutôt le rôle des applications et de l’environnement de bureau ? Les développeurs d’applications sont tout de même les mieux placés pour savoir si la tâche à effectuer nécessite ou non de la puissance. Typiquement, la vérification de nouveaux mails se ferait sur un coeur économe, tandis que l’affichage du mail par l’utilisateur se ferait sur un coeur performant.
#7.1
Pour ça, il faut que le noyau fournisse une interface permettant aux applications de qualifier la nature des traitements dans un 1er temps. Puis ensuite, il est nécessaire que les dites applications soient modifiées pour exploiter cette interface appli/noyau.
Quid des applis déjà déployées ? Du coup, il y a besoin d’une analyse / cantonnement du code ou de l’appli suivant sa nature pour permettre au noyau de distribuer les threads sur les bonnes runqueues.
Au pire, il est possible de bloquer manuellement une appli sur un ou plusieurs core suivant l’OS mais encore faut il pouvoir identifier facilement les gros cores des petits cores.