Vorige week deelde ik enkele eerste cijfers hoe verrassend het uitschakelen van de Zen 4 CPU-beveiligingsbeperkingen de CPU-prestaties van de Ryzen 7000-serie daadwerkelijk kan *schaden*. Terwijl conventionele wijsheid en met eerdere Intel/AMD-processors betere prestaties opleveren bij het uitschakelen van de CPU-beveiligingsbeperkingen, bleek dit bij de Ryzen 9 7950X eigenlijk het tegenovergestelde te zijn. Sindsdien heb ik meer tests uitgevoerd en een AMD Ryzen 5 7600X gebruikt om de eerdere resultaten te bevestigen en dieper in de gegevens te graven.
Uit de gegevens die vorige week werden gedeeld, bleek dat voor de meeste tests, het was eigenlijk sneller om de AMD Ryzen 9 7950X in zijn standaard en veilige, gemitigeerde staat te houden met nog steeds enkele softwarecontroles met betrekking tot Spectre V1/V2/V4. Dat is de out-of-the-box Linux-status voor de Ryzen 7000″Zen 4″-processors waar het opstarten van de kernel met”mitigations=off”in feite leidde tot slechtere prestaties-het tegenovergestelde vergeleken met wat we hebben gezien uit eerdere x86_64 processors.
Met behulp van een AMD Ryzen 5 7600X samen met enkele andere kleine hardware/software verschillen en grotendeels dezelfde benchmarks, herhaalde ik de tests om de bevinding van vorige week te bevestigen. En ja hoor, de Ryzen 5 7600X presteerde duidelijk beter met de standaardbeperkingen dan in de beperking=uit-status. Hier is de side-by-side op de Ryzen 5 7600X met de standaardinstellingen versus mitigations=off op Linux 6.0:
Voor de overgrote meerderheid van de benchmarks was het vasthouden aan de standaardstatus sneller dan mitigations=off. Het uitschakelen van de mitigaties hielp bij een kleine subset van tests, meestal de verschillende benchmarks voor synthetische kernels. OpenJDK Java-workloads, database-workloads, webbrowsertests en vele andere workloads die normaal negatief worden beïnvloed door de Spectre-beperkingen, werkten eigenlijk beter op dit Ryzen 5 7600X-systeem dan bij het uitschakelen van de beperkingen.
Ter herinnering, Zen 4 wordt niet beïnvloed door de meeste bekende kwetsbaarheden in de CPU-beveiliging. Wat nog steeds relevant is vanuit een softwareperspectief op basis van de CPU MSrs en toegepast met Linux 6.0 is Speculative Store Bypass uitgeschakeld via prctl voor de SSBD/Spectre V4 mitigatie en Spectre V1 mitigatie van usercopy/SWAPGS barrières en __user pointer sanitization. Dan zijn er voor Spectre V2 Retpolines, voorwaardelijke Indirect Branch Predictor Barriers (IBPB), IBRS-firmware, always-on Single Threaded Indirect Branch Predictors (STIBP) en return stack buffer (RSB) vulling.
Dus om nieuwsgierig en dieper gravend, probeerde ik enkele van de meer doelgerichte kernelopties voor deze oplossingen om te zien wat er in het bijzonder voor zorgt dat Zen 4 langzamer werkt wanneer uitgeschakeld.
Omdat SSBD is uitgeschakeld via prctl(), op de AMD Ryzen 5 7600X heb ik extra runs uitgevoerd met”spectre_v2=off”om de Spectre V2-standaardbeperking uit te schakelen en vervolgens afzonderlijk”no_spectrev1″voor het uitschakelen van de Spectre V1-beperking….
Al snel werd het duidelijk dat het vooral de Spectre V2-mitigatie was die, wanneer uitgeschakeld, de Zen 4-prestaties schaadt. Het uitschakelen van de Spectre V1-beperking betekende niet veel voor de prestaties, maar bij het uitschakelen van Spectre V2 waren er plotseling veel workloads die achteruitgingen en vergelijkbare prestaties opleverden als mitigations=off.
Voor veel verschillende workloads, het uitschakelen van de Spectre V2-beperking op de Ryzen 7000-serie deed de prestaties nu eerder pijn dan dat ze het hielpen…
Het opnemen van code-compilatie-workloads werd negatief beïnvloed door het uitschakelen van de Spectre V2-beperking dan het vasthouden aan de standaard (veilige) status.
p>
Voor veel verschillende workloads in de echte wereld bleek het nu het beste te zijn op Zen 4, waarbij het naar de standaard kernelstatus bleef in plaats van de beperkingen uit te schakelen om de prestaties te verbeteren.
Ten minste uit deze testronde weten we nu dat het specifiek de Spectre V2-beperking is die voor Zen 4 moet worden ingeschakeld om te voorkomen dat de prestaties worden aangetast, het tegenovergestelde van wat we gewend zijn te zien bij eerdere processorfamilies.
Wat betreft de reden waarom de prestaties van de Ryzen 7000-serie eigenlijk langzamer zijn als de Spectre V2-beperkingen worden uitgeschakeld, dat is waarschijnlijk iets dat alleen AMD effectief kan beantwoorden, maar waarschijnlijk komt het erop neer dat Zen 4 nu beter wordt afgestemd/geoptimaliseerd om aan te nemen dat het Spectre V2-verzachte gedrag in de micro-architectuur. In ieder geval is dit uiteindelijk goed nieuws voor eindgebruikers en degenen met productiesystemen zouden in de standaard (veilige) staat moeten draaien in plaats van te proberen de”mitigations=off”-modus te gebruiken.
Geïnteresseerden kunnen alles zien van mijn beperkende tests van de AMD Ryzen 5 7600X op Linux 6.0 via deze resultatenpagina.
