この時点で、私たちの研究の目的は明確になりました！デフォルトのLinuxスケジューラによるスレッドの自動スケジューリング、「キャッシュ最適化」スケジューラによるスケジューリング、手動によるスレッド配置制限がパフォーマンスにどのような影響を与えるかを明らかにしたいと考えています。

多くの学術プロジェクトと同様に、私たちは締め切りにかなり近づいてから着手し、すぐにテストを開始するという比較的直線的な思考プロセスをたどりました。実験のセットアップでは、コヒーレンスアクション（ソケット間で送信される所有権取得のための読み取りリクエストを介して）を追跡し、さまざまな構成でのレイテンシ数値を追跡し、実行時の変更がパフォーマンスの向上または低下にどのような影響を与えたかを正確に掘り下げようとしました。ベンチマークはすべて単一コアの容量以下のスレッド数で実行されたため、理想的なコア間配置のプロキシとして、制御のためにnumactlを使用してベンチマークを単一ソケットに制限することにしました。

これが私たちの研究全体で最も印象的な結果の1つにつながりました。標準的なLinuxスケジューラと特殊なLAVDスケジューラは、どちらもベンチマークでほぼ同じパフォーマンスを示しましたが、numactlを使用してスレッドスケジューリングを単一ソケットに制限すると、実行時間が最大3倍改善しました！

runtime_speedup_vs_eevdf_2s.png

Figure 1: ベンチマーク実行時間の正規化されたスピードアップ

マルチソケットマシンでスレッド数が十分に少ないワークロードを実行している方がいらっしゃいましたら、少なくともnumactlを使用してワークロードを単一のLLCドメインまたはコアセットに固定してみることをお勧めします。マルチスレッドの共有メモリプログラムで極めて大きなスピードアップを得られる可能性があります。これは、主にLinuxのロードバランサが、スレッド数に許される限りすべてのソケットがほぼ均等にロードされるようにしようとするためであり、それが実際にホストプログラムに不利に働く場合でもそうです。

この観察結果の顕著な例外がDCPerfから入手したmediawikiベンチマークでした。なぜ実行時間がほとんど変わらなかったのでしょうか？もしかするとキャッシュヒット率が実際に改善していなかったのかもしれません。

それが本当かどうかを確認してみましょう。所有権取得のための読み取りミス（例：L3が何かに書き込みたいがデータを持っていないため、他のコアにデータの所有権を要求する）の数が変化したかどうかを確認してみましょう。強い書き込み共有がある場合、共有キャッシュラインが2つのソケットのL3キャッシュ間でバウンドするため、この数値が上昇することが予想されます。

l3_rfo_mpki_newdata.png

Figure 2: L3キャッシュの所有権取得のための読み取りミス（1,000命令あたり）

さて、これで2つの謎ができました。

  1. mediawikiはL3 RFOの改善があったにもかかわらず、なぜ全くスピードアップしなかったのか？
  2. perlbenchでは一体何が起きているのか？なぜそれほどまでにスピードアップするのか？

残念ながら、締め切りまでにこれらの質問のどちらにも答えられませんでした。実際、この関係性を見つけたのは論文の提出日でした。深刻な睡眠不足と血流に大量のカフェインを注ぎ込みながら、問題を無視するという昔ながらの方法を取り、最終報告書に「問題を特定できなかった」と書き、プロットをさらに生成し続けました。報告書はちょうど午後11時45分に完成し、Siebelまで走って教授のドアの下に報告書をできるだけ素早く滑り込ませました。そして、提出後は私たちの誰もがそれについてもう考えることはありませんでした。

学期末から数週間後、私はこのプロジェクトで使用したトレースを整理していました。そして、何か今では忘れてしまった理由で、各ベンチマークのMIPSが気になりました。

mips_newdata.png

Figure 3: 1秒あたりの百万命令数（MIPS）で測定したスループット

これは…意味がありません。スループットは大幅に向上したのに、実行時間は変わっていない？ベンチマークの実行に使用したコマンドは何だったでしょうか？ 

cd /home/pradyun/pg_work/dcperf/
sudo ./perf_collect_mw "$JOBNAME" ./benchpress_cli.py run oss_performance_mediawiki_mlp \
    -i '{"scale_out": 1, "client_threads": 32, "duration": "10m"}' &

… 困りました。durationが10分に固定されていました。この指示はテストインフラの奥深くに埋もれており、このプロジェクトの過程で何度も再利用されたため、完全に忘れていました。

一気に、いくつかのミスが犯されました。スピードアップは命令数が一定であるという前提で計算されましたが、このベンチマークではそうではありませんでした。そして、単一ソケットのスピードアップを「変化なし」という幻の結果として誤って報告してしまっただけでなく、LAVDがより良く見えるようにした唯一のデータポイントを隠してしまったことにもなりました。後者については、mediawikiの性質がLAVDが設計されたタスクチェーンモデルに適しているというのが私の理論です。

補足: LAVDはChangwoo Min氏とIgaliaの素晴らしいチームによってSteam Deck向けに設計・最適化されました。OSPM25でのLAVDに関する彼の素晴らしい講演はこちらでご覧いただけます。ぜひご覧になることをおすすめします！