Une solution de contournement de chipset vieille de 20 ans a fait des ravages sur les récents systèmes AMD Linux

Une solution de contournement de chipset vieille de 20 ans a fait des ravages sur les récents systèmes AMD Linux

L’ingénieur AMD K Prateek Nayak a récemment révélé qu’une solution de contournement de jeu de puces vieille de près de 20 ans dans le noyau Linux, toujours implémentée sur les systèmes AMD modernes, est dans certains cas responsable des performances néfastes sur les machines Zen modernes. Heureusement, un correctif est en cours pour limiter cette solution de contournement aux systèmes plus anciens et ainsi contribuer aux performances des systèmes modernes.

la semaine dernière était correction Il a été publié pour le code d’inactivité du processeur ACPI afin d’éviter une solution de contournement de chipset obsolète sur les systèmes AMD Zen modernes. Depuis que le support ACPI a été ajouté au noyau Linux en 2002, il y a eu une « commande d’attente factice » pour gérer certaines puces où STPCLK # n’est pas confirmé à temps. La lecture d’E/S fantôme retarde le traitement d’instructions supplémentaires jusqu’à ce que le CPU soit complètement arrêté. Cela a été un problème au moins avec certains systèmes de l’ère AMD Athlon avec des puces VIA… mais pas un problème avec les puces plus récentes au cours des deux dernières décennies environ.


Le noyau Linux des deux dernières décennies est toujours implémenté inutilement pour les chipsets plus anciens sur les systèmes AMD modernes, ce qui peut à son tour compromettre les performances sur des charges de travail spécifiques.

Cette solution étant toujours appliquée aux systèmes AMD modernes, K Prateek Nayak a découvert :

L’échantillonnage de certaines charges de travail à l’aide d’IBS sur un système AMD Zen3 montre qu’une quantité importante de temps est consacrée au processus fictif, qui est incorrectement calculé comme résidence dans l’état C. Une grande valeur de résidence dans C-State peut demander au gouverneur de CPU de recommander un état C plus profond pendant les états d’inactivité ultérieurs, initiant un cercle vicieux, dégradant les performances dans les charges de travail qui passent rapidement entre les phases occupées et inactives.

L’une de ces charges de travail est tbench, où une dégradation massive des performances peut être observée lors de certaines exécutions.

Au moins pour Tbench, cette solution de contournement inconditionnelle dans le noyau Linux nuisait aux performances d’AMD Ryzen/Threadripper/EPYC sur des charges de travail spécifiques :

READ  Konami met fin à Super Bomberman R en ligne et avance avec de « nouveaux projets »

Cette solution de contournement n’a pas affecté les systèmes Intel plus récents, car les plates-formes Intel plus récentes utilisent à la place le chemin de code du pilote Intel_idle basé sur MWAIT.

L’évolution du patch AMD en Ce correctif Par l’ingénieur Intel Linux Dave Hansen. Ce correctif pour réduire une solution « d’attente fantôme » sur les systèmes hérités est déjà en file d’attente dans la branche x86/urgent de TIP. En suivant le chemin « x86/urgent » et pour corriger une solution de contournement trop zélée qui n’est pas nécessaire sur les machines modernes, cette semaine, ce correctif sera probablement envoyé au noyau Linux 6.0 plutôt que d’attendre la prochaine fenêtre de fusion (v6.1) .

Valère Paget

"Fanatique maléfique de la télévision. Fier penseur. Wannabe pionnier d'Internet. Spécialiste de la musique. Organisateur. Expert de la culture pop hardcore."

Related Posts

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Read also x