Behebt die von Torvalds beobachtete starke Verschlechterung der Linux-Leistung

Bevor Linus Torvalds aufgrund eines Schneesturms sein Internet und seinen Strom verlor und dadurch das Linux 6.8-Integrationsfenster beeinträchtigte, war sein Wochenende aufgrund eines Leistungseinbruchs mit neuem Linux 6.8-Code, der die Erstellung seines Linux-Kernels verursachte, bereits in einer schwierigen Verfassung. Es ist doppelt so hoch wie bei früheren Kernen. Ein AMD-Linux-Ingenieur konnte die Regression reproduzieren und gemeinsam mit den leitenden Entwicklern gibt es nun eine bestätigte Lösung für dieses Problem im neuesten Planungscode.

Bei der Erörterung des von Linus Torvalds berichteten erheblichen Leistungsrückgangs, der sich aus den Scheduler-Änderungen in Linux 6.8 für Split-Commit ergab, war dem beteiligten Entwickler nicht sofort klar, was den Rückschritt verursachte. In der anschließenden Diskussion sprach Wise Carney von AMD erwähnt Es kann auch eine Regression reproduzieren. Anstelle eines High-End-AMD Ryzen Threadripper, wie ihn Torvalds verwendet, verwendete Wyes einen bescheidenen AMD Ryzen 5600G-Desktop. Ein wichtiger Hinweis, den er ansprach, ist, dass dies nur reproduziert wird, wenn Sie ACPI CPPC im BIOS deaktivieren und ACPI CPUFreq mit dem Schedutil-Governor verwenden.

Die meisten AMD Zen 2- und neueren Systeme unterstützen ACPI CPPC, sodass sie bei modernen Kernen auf der Ryzen-Seite normalerweise den neuen AMD P-State-Treiber verwenden. Aber für Zen 2/Zen 3 und frühere Systeme (oder solche, die CPPC im BIOS deaktivieren) wird weiterhin der CPUFreq-Treiber verwendet und der standardmäßige CPU-Frequenzregler ist normalerweise „Schedutil“, um die Nutzungsdaten des Schedulers zu nutzen.

In diesem Thread auf der Mailingliste wurde eine Korrektur vorgeschlagen und spezifische Probleme mit dieser Regression besprochen. Schließlich glaubte Vincent Guiteau, eine Lösung für die Regression zu haben, und Wise konnte den Patch erfolgreich testen.

Guittot wurde nun gesendet Geplant/Fair: Frequenzauswahl für instabilen Fall korrigieren Als Patch zur Behebung dieser schlechten Regression auf neuem Linux 6.8-Code bei Verwendung von ACPI CPUFreq + Schedutil. Erklärt mit Korrektur:

„Wenn die Frequenzpersistenz nicht aktiviert ist, gibt get_capacity_ref_freq(policy) die aktuelle Frequenz und den von map_util_perf() angewendeten Leistungsspielraum zurück, sodass die Nutzung die maximale Rechenkapazität überschreiten und eine höhere Frequenz als die aktuelle Frequenz auswählen kann.

Die Leistungsmarge wird jetzt früh in der Pipeline angewendet, um einige Nutzungsbeschränkungen zu berücksichtigen, und wir können keine Auslastung erreichen, die über der maximalen Rechenkapazität liegt.

Wir müssen eine höhere Frequenz als die aktuelle Frequenz verwenden, um eine Chance zu haben, einen höheren OPP einzustellen, wenn die aktuelle Frequenz vollständig genutzt wird. Wenden Sie den gleichen Spielraum an und geben Sie eine Frequenz zurück, die 25 % höher ist als die aktuelle Frequenz, um zum nächsten OPP zu wechseln, bevor wir die gesamte CPU im aktuellen Prozessor verbrauchen.“

Letztendlich war es eine einzeilige Codekorrektur zur Behebung dieses Leistungsabfalls, die dazu führte, dass die leeren Kernel-Builds von Linus Torvalds von 22 Sekunden auf 44 Sekunden anstiegen.

Vorausgesetzt, dass mit dem neuen Patch weiterhin alles gut läuft, sollte der Fix in den Git-Code von Linux 6.8 Eingang finden, sobald die Internet- und Stromversorgung von Linus Torvalds wiederhergestellt ist.