Nolan Mariotte
Lorsque Meteor Lake a été lancé sur le marché à partir de Linux, il était clair que quelque chose n'allait pas. Quelques correctifs plus tard, Intel a atteint les performances attendues et devançait AMD par le minimum en termes de CPU, avec également une efficacité plus élevée. Contrairement aux rouges, qui publieront des cœurs hybrides avec Zen 5 pour presque toutes les plates-formes, Intel l'a fait avant et cela signifie que sous Linux, les correctifs, les pilotes et le noyau ont dû être adaptés. Par conséquent, Intel a maintenant présenté ce qui sera une série de 3 correctifs pour obtenir de meilleures performances avec P-State sous Linux grâce à de nouveaux pilotes.
Comme le rapporte Phoronix et comme nous pouvons le voir dans le référentiel du noyau Linux, à la fin du mois dernier, Rafael Wysocki, programmeur informatique et chef de projet logiciel chez Intel, a lancé la demande de trois correctifs qui devraient entraîner de meilleures performances et efficacité pour tout processeur doté de des cœurs hybrides au sein de x86 et de ce système d'exploitation, mais de quoi s'agit-il réellement ?
Le noyau Linux fonctionnera mieux grâce à trois parties et un pilote pour les P-States des processeurs Intel hybrides
L'information asymétrique en tant que concept que nous allons voir ci-dessous, selon Wysocki lui-même, n'est rien de plus que la capacité du logiciel à comprendre, déplacer et travailler sur l'information entre différents types de noyaux. Dans ce cas et comme on le sait, P-Core et E-Core, ainsi que le LP-E qui feraient également partie de ce dernier.
Par conséquent, Vysocki parle de ces correctifs en disant que :
Le but et l'objectif de cette série sont de fournir au programmeur des informations asymétriques sur la capacité du processeur dans les systèmes hybrides x86 basés sur du matériel Intel. Les informations asymétriques sur la capacité du processeur sont importantes dans les systèmes hybrides, car elles permettent de calculer l'utilisation des tâches de manière cohérente sur tous les processeurs du système, quelle que soit leur capacité.
10/09/2024 à 06:58
Ceci, à son tour, permet au gouverneur « schedutil cpufreq » de définir les niveaux de performances du processeur de manière cohérente dans les cas où les tâches migrent entre des processeurs de capacités différentes. Il devrait également contribuer à améliorer les décisions en matière d'allocation des tâches et d'équilibrage de charge dans les systèmes hybrides et constitue un élément clé pour tout ce qui concerne l'EAS.
Les informations en question proviennent du registre “MSR_HWP_CAPABILITIES” et du pilote “intel_pstate”, qui fournissent au programmeur ce qui est nécessaire selon le changelog du patch. [3/3]. Le patch [2/3] présente l'infrastructure arch nécessaire pour cela (sous la forme d'une variable de capacité par CPU) et le correctif [1/3] Il s'agit d'un ajustement préliminaire du code.
Tous ne sont pas des avantages, il y aura une légère surcharge dans l'accès à la mémoire
Vysocki affirme qu'il existe un léger compromis, qui, en revanche, ne devrait pas vraiment affecter l'augmentation des performances :
Modifications apportées par le patch [2/3] Ils sont très simples, c'est pourquoi cette série est soumise sous forme de RFC. Autrement dit, cela augmente les frais généraux dans les systèmes hybrides et non hybrides, ce qui peut être considéré comme inacceptable, bien que l’augmentation des frais généraux ne soit sans doute pas significative.
La surcharge de mémoire est une variable “longue” non signée par le CPU qui n'est pas très IMV et il y a également une surcharge d'accès mémoire supplémentaire sur chaque site de “call arch_scale_cpu_capacity()” qui, cependant, je ne m'attends pas à être résolue. note. En cualquier caso, la sobrecarga adicional se puede evitar a costa de hacer el código un poco más complejo (por ejemplo, la memoria adicional por CPU se puede asignar dinámicamente solo en sistemas híbridos y se puede usar una rama estática para permitir el acceso a él quand il soit nécessaire).
Je ne sais tout simplement pas si la complexité supplémentaire en vaut vraiment la peine, j'aimerais donc entendre les responsables x86 à ce sujet.
