Linux entfernte einen Leerlauf-Workaround aus dem Jahr 2002, und der AMD-Zen-Durchsatz stieg um bis zu 14x

Als 2002 ACPI-Unterstützung in den Linux-Kernel aufgenommen wurde – geschrieben von Andy Grover, committet von Linus Torvalds –, enthielt sie eine „Dummy-Wait-Operation“: Das System las Daten ohne anderen Zweck, als die nächste Instruktion zu verzögern, bis die CPU mit dem STPCLK#-Befehl vollständig anhalten konnte. Das brachte in den frühen Tagen Energieeinsparungen und Kompatibilität, als einige Chipsätze sich weigerten, wie erwartet in Leerlaufzustände zu wechseln.

Zwanzig Jahre später reichte der AMD-Ingenieur Prateek Nayak einen Kernel-Patch ein, um „den Dummy-Wait für Prozessoren auf Basis der Zen-Mikroarchitektur zu überspringen“. Moderne Zen-Chips brauchen einen solchen Anstoß nicht, und Tests mit instruktionsbasierter Stichprobenentnahme zeigten, dass die Dummy-Operation weiterhin erhebliche Zeit verbrauchte, die der Kernel fälschlicherweise als C-State-Residenz verbuchte. Angesichts all dieser mühelosen Arbeit drängte sich die CPU selbst in tiefere, langsamere C-States und brauchte dann länger zum Aufwachen – was Jobs beeinträchtigte, die ständig zwischen beschäftigt und im Leerlauf wechseln.

Die Messungen waren dramatisch: In tbench-Läufen auf einem Dual-Socket-Zen3-System lieferte der gepatchte Kernel einen Anstieg des minimalen MB/s-Durchsatzes um 1.390 % und einen Anstieg des mittleren MB/s um 51 % gegenüber dem Baseline-Kernel und kam damit nahe an das Ergebnis des vollständigen Deaktivierens des C2-Schlafzustands heran.

Intel-Systeme waren dem Altlastenfluch ein Jahrzehnt lang dank eines MWAIT-basierten Leerlaufmechanismus entgangen, und Intels Dave Hansen reichte einen dringenden Patch ein, der den Dummy-Wait auf Intel-Systeme beschränkte – wo er „annähernd moderne“ Maschinen nicht beeinflussen würde –, plus Kommentare, die Leser drängten, zu moderneren Leerlaufmechanismen zu wechseln. Rechtzeitig eingereicht, könnte der Fix es in den Linux-6.0-Kernel schaffen, der in der folgenden Woche ausgeliefert werden sollte.

Ein No-op-Lesevorgang aus dem Jahr 2002 wurde von der Energieverwaltung als Beweis für leichte Last fehlinterpretiert und drängte Zen-Kerne in Tiefschlaf – seine Entfernung erhöhte den Mindestdurchsatz um 1.390 %.

Die Diagnose ist das Geniale: Instruktionsbasierte Stichprobenentnahme zeigte, dass verschwendete Zeit als gesunder Schlaf fehletikettiert wurde, wodurch ein Buchhaltungsfehler der Energieverwaltung zu einer sichtbaren Leistungsklippe wurde.

Der Fix kostet einen Branch – den Dummy-Wait auf Zen überspringen –, holt aber den vierzehnfachen Mindestdurchsatz zurück, ein Verhältnis, das durch Optimierung echter Arbeit selten erreichbar ist.

Es ist ein lebendes Exemplar technischer Schuld: Für Chipsätze von 2002 hinzugefügter Code überlebte zwei Jahrzehnte und mehrere CPU-Generationen, weil nie etwas fehlschlug – es wurde nur langsamer.

Kompatibilitäts-Shims überleben die Hardware, der sie dienen: Wenn niemand sie gegen neue Silizium prüft, kann ein 20 Jahre alter No-op zu einer unsichtbaren Steuer werden, die wie ein Chip-Problem aussieht.

Nayaks Zen-Patch und Hansens dringender Folge-Patch, der den Dummy-Wait auf Intel-Systeme beschränkte, wurden Ende September 2022 eingereicht, rechtzeitig für eine Berücksichtigung im Linux-6.0-Kernel, den Torvalds in der folgenden Woche auszuliefern erwartete. Intels Patch fügte außerdem Kommentare hinzu, die zur Migration auf moderne Leerlaufmechanismen ermutigten. Ars Technica berichtete, dass es für AMD-Systeme nach dem Einspielen des Patches keine verbleibenden Probleme gab.