La semaine dernière, j’ai partagé quelques chiffres initiaux à quel point la désactivation des atténuations de sécurité du processeur Zen 4 peut en fait * nuire * aux performances du processeur de la série Ryzen 7000. Alors que la sagesse conventionnelle et les anciens processeurs Intel/AMD offrent de meilleures performances lors de la désactivation des atténuations de sécurité du processeur, avec le Ryzen 9 7950X, il s’est avéré que c’était fondamentalement le contraire. Depuis, j’ai effectué plus de tests et j’ai utilisé un AMD Ryzen 5 7600X pour confirmer les résultats précédents et approfondir les données.
Les données partagées la semaine dernière ont montré que pour la plupart des tests, il était en fait plus rapide de maintenir l’AMD Ryzen 9 7950X dans son état atténué par défaut et sécurisé tout en conservant certains contrôles logiciels relatifs à Spectre V1/V2/V4. C’est l’état Linux prêt à l’emploi pour les processeurs Ryzen 7000″Zen 4″où le démarrage du noyau avec”mitigations=off”entraînait en fait de moins bonnes performances-le contraire par rapport à ce que nous avons vu avec x86_64 plus tôt processeurs.
En utilisant un AMD Ryzen 5 7600X avec quelques autres légères différences matérielles/logicielles et principalement les mêmes références, j’ai répété les tests juste pour confirmer la découverte de la semaine dernière. Et bien sûr, le Ryzen 5 7600X fonctionnait clairement mieux avec les atténuations par défaut que dans l’état atténuations=désactivé. Voici le côte à côte sur le Ryzen 5 7600X avec les valeurs par défaut par rapport à mitigations=off sur Linux 6.0 :
Pour la grande majorité des benchmarks, le maintien de l’état par défaut était plus rapide que mitigations=off. La désactivation des atténuations a aidé dans un petit sous-ensemble de tests, principalement les différents benchmarks du noyau synthétique. Les charges de travail OpenJDK Java, les charges de travail de base de données, les tests de navigateur Web et de nombreuses autres charges de travail normalement affectées négativement par les atténuations Spectre fonctionnaient en fait mieux sur ce système Ryzen 5 7600X que lors de la désactivation des atténuations.
Pour rappel, Zen 4 n’est pas affecté par la plupart des vulnérabilités de sécurité CPU connues. Ce qui est toujours pertinent d’un point de vue logiciel basé sur les MSR du processeur et appliqué avec Linux 6.0 est le contournement spéculatif du magasin désactivé via prctl pour l’atténuation SSBD/Spectre V4 et les atténuations Spectre V1 des barrières usercopy/SWAPGS et la désinfection du pointeur __user. Ensuite, pour Spectre V2, il y a des retpolines, des barrières conditionnelles de prédiction de branche indirecte (IBPB), un micrologiciel IBRS, des prédicteurs de branche indirecte à thread unique (STIBP) et un remplissage de tampon de pile de retour (RSB).
Alors, pour creusant plus profondément et étant curieux, j’essayais certaines des options de noyau les plus ciblées pour ces atténuations afin de voir ce qui ralentissait en particulier Zen 4 lorsqu’il était désactivé.
Avec SSBD désactivé via prctl() , sur l’AMD Ryzen 5 7600X, j’ai exécuté des exécutions supplémentaires avec”spectre_v2=off”pour désactiver l’atténuation par défaut de Spectre V2, puis séparément”no_spectrev1″pour désactiver l’atténuation de Spectre V1…
Assez rapidement, il est devenu clair que c’était l’atténuation du Spectre V2 en particulier qui, lorsqu’elle était désactivée, nuisait aux performances du Zen 4. La désactivation de l’atténuation de Spectre V1 n’a pas eu d’incidence sur les performances, mais lors de la désactivation de Spectre V2, de nombreuses charges de travail régressaient soudainement et obtenaient des performances similaires à mitigations=off.
Pour de nombreuses charges de travail différentes, la désactivation de l’atténuation de Spectre V2 sur la série Ryzen 7000 nuisait désormais aux performances au lieu de les aider…
Les charges de travail de compilation de code étaient négativement affectées par la désactivation de l’atténuation Spectre V2 plutôt que par le maintien de l’état par défaut (sécurisé).
>
Pour de nombreuses charges de travail réelles différentes, il s’est avéré qu’il valait mieux maintenant sur Zen 4 laisser l’état du noyau par défaut plutôt que de désactiver les atténuations en essayant d’améliorer les performances.
Au moins à partir de cette série de tests, nous savons maintenant que c’est spécifiquement l’atténuation Spectre V2 qui doit être laissée pour Zen 4 pour éviter de nuire aux performances, à l’opposé de ce que nous avons l’habitude de voir avec les familles de processeurs précédentes.
Comme pour w hy les performances de la série Ryzen 7000 sont en fait plus lentes si vous désactivez les atténuations Spectre V2, c’est probablement quelque chose que seul AMD peut répondre efficacement, mais cela revient probablement à ce que Zen 4 soit mieux réglé/optimisé maintenant pour assumer le comportement atténué Spectre V2 dans la micro-architecture. Dans tous les cas, c’est finalement une bonne nouvelle pour les utilisateurs finaux et ceux qui ont des systèmes de production devraient fonctionner dans l’état par défaut (sécurisé) plutôt que d’essayer d’exécuter le mode”mitigations=off”.
Les personnes intéressées peuvent voir tout de mes tests d’atténuation de l’AMD Ryzen 5 7600X sur Linux 6.0 via cette page de résultats.
