Performance-Schwäche bei AMDs Phenom II X6 unter Linux

Wissen | Hintergrund

Der Linux-Kernel kommt mit einer Neuerung in AMDs neuem Sechskernprozessor nicht klar, wodurch die CPU nur mit Patches ihre volle Leistung erreicht.

Die-Shot einer Hexa-Core-CPU von AMD

AMDs kürzlich eingeführte Desktop-Prozessoren wie der Sechskerner Phenom II X6 1090T entfalten bei vielen aktuellen Linux-Distributionen nicht ihr volles Geschwindigkeitspotenzial, weil der Kernel die korrekten Prozessor-Frequenzen nicht aus den ACPI-Tabellen ausliest – dadurch wird der Kernel so verwirrt, dass der Prozessor in vielen Konfigurationen seine Nominalfrequenz nicht erreicht.

Turbo Core ist eine mit den Sechskernern eingeführte und durch das "T" in der Prozessorbezeichnung gekennzeichnete Funktion, die Intels "Turbo Boost" ähnelt: Haben einzelne Prozessor-Kerne gerade nichts zu tun, können andere Prozessor-Kerne ein wenig schneller laufen, um die anstehende Arbeit zügiger zu erledigen, ohne das Kühlsystem zu überfordern. Der normalerweise mit 3,2 GHz arbeitende 1090T etwa kann bis zu drei seiner Kerne vorübergehend mit 3,6 GHz betreiben, wenn die anderen drei untätig sind.

Turbo Core beziehungsweise Turbo Boost interagieren mit den Stromsparfunktionen, die einzelne Kerne oder den ganzen Prozessor heruntertakten und die Spannung absenken, um die Leistungsaufnahme zu reduzieren, wenn es nichts zu tun gibt. Das wird AMDs neuen Prozessoren zum Verhängnis, denn sobald die dort "Cool'n'Quiet" genannte Funktion aktiv ist, schalten die Prozessoren mit Turbo Core bei aktuellen Linux-Kerneln nicht mehr auf den Nominaltakt hoch, sondern arbeiten ein wenig langsamer.

Anwender können das Problem am einfachsten umgehen, wenn sie "Cool'n'Quiet" deaktivieren. Dazu schaltet man die Funktion im BIOS-Setup des Boards komplett aus oder weist den Kernel an, keine Taktanpassungen mittels Cpufreq durchzuführen – bei der Linux-Distribution Fedora erreicht man Letzteres, indem man den Daemon "cpuspeed" stoppt, bei anderen muss man das für Cpufreq bei modernen AMD-CPUs zuständige Kernel-Module powernow-k8 blacklisten. Durch das Lahmlegen der Stromsparfunktion kann sich allerdings die Leistungsaufnahme des Gesamtsystems im Leerlauf um 10 bis 20 Watt erhöhen.

Den bei AMD beschäftigten Kernel-Entwicklern ist das Problem seit Kurzem bekannt. Es wird durch die bereits im März zur Begutachtung an die Kernel-Entwickler gesendete Änderungen behoben, die für eine ordentliche Unterstützung von Turbo Core unter Linux sorgen sollen und aller Wahrscheinlichkeit in Linux 2.6.35 eingehen. Letztendlich ist laut den AMD-Mitarbeitern aber nur einer der Patches nötig, um die Performance-Schwäche zu beseitigen. Nach Bekanntwerden des Problems soll dieser nur eine Zeile Quellcode verändernde Patch nun in Kürze in den derzeit noch in Entwicklung befindlichen Linux-Kernel 2.6.34 einfließen. Anschließend soll er in die derzeit gepflegten Kernel der Stable-Series integriert werden – wann aber neue Versionen der Linux-Kernel-Serien 2.6.32.x und 2.6.33.x mit dieser Änderung erscheinen, ist bislang nicht abschätzbar. AMD-Mitarbeiter stehen zudem in Kontakt mit den Entwicklern verschiedener Distributionen, damit auch diese den Patch in ihre über die Update-Funktionen ausgelieferten Kernel integrieren.

[Update 20100505-0815] Linus Torvalds hat den eine Zeile verändernden Patch mittlerweile in den zu Linux 2.6.34 führenden Hauptentwicklungszweig integriert. [/Update]

Einige Versuche mit einer Vorabversion von Fedora 13 und verschiedenen Kerneln auf Basis des zu dieser Distribution gehörenden Linux-Kernels 2.6.33.2-57.fc13.x86_64 zeigten die Auswirkungen des Problems und die Funktion der Kernel-Patches. Zum Kompilieren von Linux 2.6.25 mit maximal zwölf Prozessen ("make -j 12 bzImage") in Standardkonfiguration ("make defconfig") mit Hilfe des Benchmarks "kcbench" brauchte ein Testsystem mit Phenom II X6 1090T zirka 75 Sekunden. Rund 20 Sekunden früher war der Kompiliervorgang beendet, wenn Cool'n'Quiet via BIOS-Setup oder durch Stoppen von Cpuspeed deaktiviert war. Ein selbstkompilierter Kernel mit dem oben erwähnten und nur eine Zeile verändernde Patch brauchte bei aktivem Cpuspeed allerdings 59 Sekunden – also vier Sekunden länger. Bei einem Kernel, der alle sechs Änderungen der für 2.6.34 ausgelegten Patch-Serie enthielt, war das Kompilieren bei aktivem Cpuspeed hingegen bereits nach zirka 52,5 Sekunden abgeschlossen. (thl)

Kommentare

Kommentare lesen (74 Beiträge)

Anzeige