解決策
2002年にLinuxカーネルへACPIサポートが追加されたとき — Andy Groverが執筆し、Linus Torvaldsがコミットした — そこには「ダミー待機操作」が含まれていた。これは、CPUがSTPCLK#コマンドで完全に停止できるまで次の命令を遅延させるためだけに、システムがデータを読み取るというものだった。当時、一部のチップセットが期待通りにアイドル状態へ移行しなかったため、これによって電力節約と互換性が得られた。
20年後、AMDのエンジニアPrateek Nayakは「Zenマイクロアーキテクチャに基づくプロセッサではダミー待機をスキップする」カーネルパッチを提出した。現代のZenチップにはそのような後押しは不要であり、命令ベースサンプリングを用いたテストでは、ダミー操作が依然としてかなりの時間を消費し、カーネルがそれをC-state滞在時間として誤って計上していることが示された。その低負荷に見える作業をすべて見て、CPUはより深く遅いC-stateへ自ら入り、その後起動に時間がかかるようになり、ビジーとアイドルを絶えず切り替えるジョブに悪影響を与えていた。
測定結果は劇的だった。デュアルソケットのZen3システムでのtbench実行において、パッチ適用カーネルはベースラインカーネルと比べて最小MB/sスループットが1,390%増加し、平均MB/sが51%増加し、C2スリープ状態を完全に無効化した結果に近い値となった。
IntelシステムはMWAITベースのアイドル機構のおかげで10年間このレガシーの呪いを回避していた。IntelのDave Hansenは、ダミー待機をIntelシステムに限定する緊急パッチを提出した — そこでは「リモートに現代的な」マシンには影響しない — さらに、より現代的なアイドル機構へ移行するよう読者に促すコメントも添えた。間に合うように提出されたため、この修正は翌週出荷予定のLinux 6.0カーネルに反映され得た。
達成されたこと
2002年のno-op読み取りが、電力管理によって軽負荷の証拠と誤解され、Zenコアを深いスリープへ押し込んでいた — それを削除することで最小スループットが1,390%向上した。
診断こそが天才的である。命令ベースサンプリングにより、無駄な時間が健全なスリープとして誤ってラベル付けされていることが明らかになり、電力管理の計上バグが目に見える性能の崖へと変わっていた。
修正のコストは1つの分岐 — Zenでダミー待機をスキップする — だけだが、最小スループットを14倍回復する。これは実際の作業の最適化ではめったに達成できない比率である。
これは技術的負債の生きた標本である。2002年のチップセットのために追加されたコードが、何も失敗せず、ただ遅くなるだけだったために、20年間と複数のCPU世代を生き延びた。
応用できること
互換性のためのシムは、それが対象とするハードウェアより長生きする。新しいシリコンに対して誰かが再監査しない限り、20年前のno-opがチップの問題に見える目に見えない税になり得る。
その後
NayakのZenパッチと、ダミー待機をIntelシステムに限定するHansenの緊急フォローアップは2022年9月下旬に提出され、Torvaldsが翌週出荷予定としていたLinux 6.0カーネルでの検討に間に合った。Intelのパッチはまた、現代的なアイドル機構への移行を促すコメントも追加した。Ars Technicaは、パッチが適用されるとAMDシステムに残存する問題はなかったと報じた。
出典をたどる
出典
- 20-year-old Linux workaround is still slowing down AMD systems Ars Technica · arstechnica.com ·