> [!abstract] 概要(SIGCOMM 2025 abstract の日本語訳) > CXL.mem とそれが実現するメモリプールは有望であり、大きな注目を集めている。ローカルメモリとは異なり、CXL DIMM は I/O サブシステム側に位置しており、その劣った性能は容易にプロセッサパイプラインとメモリサブシステムに影響を与え、性能干渉・ハードウェア競合・不明瞭な挙動・通信/計算資源の未活用を生じさせる。しかし、我々のコミュニティには CPU とリモート DIMM 間の CXL.mem プロトコル実行をエンドツーエンドで理解・プロファイルするツールが欠けている。 > 本論文はこのギャップを、体系的・情報豊富・軽量な CXL.mem プロファイラである PathFinder を設計・実装することで埋める。PathFinder は既存のハードウェア性能モニタ(PMU)の能力を活用し、CXL.mem プロトコルを適切な粒度で解剖する。我々の中心的な着想は、サーバプロセッサとそのチップセットを多段 Clos ネットワークとみなし、各アーキテクチャモジュールに PMU ベースのテレメトリエンジンを装備し、異なる CXL.mem パスを追跡し、従来のトラフィック解析技術を適用することである。PathFinder はスナップショットベースのパス駆動プロファイリングを実行し、パス構築・スタックサイクル分解・干渉解析器・スナップショット横断解析という 4 つの技術を導入する。我々は PathFinder を Linux Perf 上に構築し、7 つのケーススタディに適用する。 ## 論文情報 - タイトル: Understanding and Profiling CXL.mem Using PathFinder - 著者・所属: [[Xiao Li]]([[University of Wisconsin-Madison]] / [[Beihang University]])、[[Zerui Guo]]([[University of Wisconsin-Madison]])、[[Yuebin Bai]]([[Beihang University]])、[[Mahesh Ketkar]]([[Intel]])、[[Hugh Wilkinson]]([[Intel]])、[[Ming Liu]]([[University of Wisconsin-Madison]]) - 媒体・発表年: ACM SIGCOMM 2025 Conference(SIGCOMM '25)、2025年9月8-11日、Coimbra, Portugal。22ページ - DOI: https://doi.org/10.1145/3718958.3750479 - コード: https://github.com/netlab-wisconsin/PathFinder(オープンソース) ## 概要 CXL.mem はホスト CPU がロード/ストア命令でリモート DIMM に直接アクセスできるプロトコルであり、メモリプーリングの鍵技術である。しかし CXL メモリはローカルメモリより本質的に低速であり(SPR サーバでの計測ではローカルメモリのランダムアクセスレイテンシ 103.2ns・帯域 131.1GB/s に対し、CXL DIMM は 355.3ns・17.6GB/s)、この性能差はプロセッサパイプラインを頻繁にストールさせ、メモリサブシステムのアクセス特性を変化させる。本論文は、この CXL.mem 実行を理解・診断するための体系的プロファイラ PathFinder を提案する。サーバプロセッサとそのチップセットを多段 Clos ネットワークとみなし、各アーキテクチャモジュール(コア・CHA・アンコア・CXL デバイス)に PMU ベースのテレメトリエンジンを装備することで、232 種の PMU カウンタから CXL.mem の実行を可視化する。 ## 問題設定 CXL.mem のプロファイリングには 3 つの challenge がある。第一に、CXL.mem は §2.2 で定義される 4 種のデータパス(DRd・DWr→RFO・RFO・HW/SW PF)を持ち、コンピュート・メモリ・I/O 基盤にまたがる非透過的な経路である。第二に、CXL.mem のロード/ストア命令は深いアウトオブオーダーのプロセッサパイプラインとナノ秒粒度で密結合しており、実行状態を問い合わせるインタフェースがほとんど存在しない。第三に、ローカルメモリと CXL メモリのストリームが同一のハードウェアを共有・交錯するため、両者の挙動を個別に切り分けることが困難である。 既存の対処法は、マイクロアーキテクチャレベルの Top-Down Analysis(Intel VTune・AMD uProf 等)、メモリサブシステムのレイテンシ-帯域曲線ベンチマーク([13, 43, 80])、PCIe/インターコネクトのベンチマーキングフレームワーク([55, 69, 86])を個別に組み合わせるアドホックな手法であり、いずれもエンドツーエンドの診断能力を欠く。 ## 提案手法 - **システムモデル(Clos ネットワークとしての抽象化)**: サーバシステムを $G=(V,E)$ として表現する。$V$ はアーキテクチャモジュール(コア・SB・LFB・L1D・L2・CHA・CXL DIMM)、$E$ はオンコア FIFO・メッシュインターコネクト・FlexBus 等の相互接続リンクである。コア(ソースノード)から DIMM(デスティネーションノード)への各要求は「ローカル/CXL メモリフロー(mFlow)」として定義され($Core_i \leftrightarrow lDIMM_j/cDIMM_j$)、mFlow はさらにデータ提供位置に基づき複数の「パス」($P$)へ分岐する。PathFinder は OS スケジューリングエポックの終端(またはプリエンプション発生時)にすべての PMU のスナップショットを取得し、実行中の mFlow に紐付ける。 **Figure 1: Intel SPR/EMR プロセッサにおける4種のCXL.memデータパス** ![[_attachments/pathfinder-sigcomm25/fig01-cxl-mem-data-paths.png]] (Figure 1. コア(Core 1〜N)から Mesh Interconnect・CHA(Caching and Home Agent)を経て MClocal/MCcxl・DIMM に至る経路を示す。DRd(demand read)は L1D→LFB→L2→CHA(LLC スライス)→メッシュ経由でメモリコントローラへ、DWr(demand write)は Store Buffer(SB)経由で RFO(read for ownership)コヒーレンスメッセージを発行してから WriteBack として書き込まれる。SW/HW PF(ソフト/ハードウェアプリフェッチ)は DRd/RFO を非同期に誘発する。Source: Figure 1.) - **PathFinder のワークフロー(4技術)**: PathFinder は (a) PFBuilder(§4.3) がスナップショットごとに CXL データパスマップを構築し、(b) PFEstimator(§4.4) が back-propagation アルゴリズムでボトムアップに CXL 起因のスタックサイクルを CPU パイプラインへ帰属させ、(c) PFAnalyzer(§4.5) がホワイトボックスモデリングで各アーキテクチャコンポーネントをズームインし、並行する CXL/非 CXL ストリームの干渉を解析し、(d) PFMaterializer(§4.6) が内部時系列データベースにスナップショットダイジェストを投入し、データローカリティ・競合・資源未活用といった一貫した実行特性を同定する。 **Figure 5: PathFinderのシステム概要** ![[_attachments/pathfinder-sigcomm25/fig05-pathfinder-system-overview.png]] (Figure 5. (a) プロファイリングタスク仕様(プロファイル対象アプリケーション・実行環境・プロファイラ設定・レポート仕様)。(b) システムモデル: Core→SB→L1D→LFB→L2→CHA(Stage 1〜6)を経てUncore→FlexBus→DIMM(Stage 7〜9)に至る各段に PTE(PMU-based Telemetry Engine)を配置し、Path i・Path j のような複数経路を並行追跡する。(c) PathFinder ワークフロー: Step 1 PFBuilder が App から mFlow・Path を構築(Intra-Snapshot Analysis 開始)、Step 2 PFEstimator が各ステージのスタックを推定、Step 3 PFAnalyzer が Culprit path(ボトルネック経路)と Victim path(被害経路)を判別、Step 4 PFMaterializer が Time-Series Database に Snapshot を蓄積して Tasks/Queries に応答する(Inter-Snapshot Analysis)。Source: Figure 5.) - **PFBuilder(パスマップ構築、§4.3)**: traceroute はコンピュータネットワークでは経路上のルータを特定する標準技術だが、オンチップのマイクロアーキテクチャハードウェアはプログラム可能でないため直接適用できない。そこで PathFinder は、PMU がパス固有のヒット/ミス情報を異なる位置で報告するという事実を利用し、スナップショット内でパスマップを再構築する。各 mFlow についてホームコアの PMU から SB・L1D・LFB・L2 での DRd/RFO/PF/DWr ヒット数に基づきパス毎のトラフィック負荷を計算し、次に CHA PMU をトップダウンに解析する。Intel プロセッサが持つ TOR(Table of Requests、コア-CCA マッピングを記録するハードウェアモジュール、`unc_cha_tor_inserts` カウンタで観測可能)を用いて、L2 以降の欠落コマンドのパスマップ構築を継続する(AMD Zen プロセッサにも機能的に同等のコンポーネントが CCD に存在する)。LLC ミスはローカル LLC スライス→(チップレット構成なら)Sub-NUMA クラスタ内の distant LLC スライス→他ソケットの remote LLC スライスの順で snooping により解決され、最終的に MC・DIMM へ到達する。 - **PFEstimator(スタックサイクル分解、back-propagation アルゴリズム、§4.4)**: コンピュータネットワークの reverse traceroute [60] に着想を得て、CXL_DIMM の MC から出発し、現在のスナップショットで要求を発行した FlexBus RC(root access port)を特定し、そのトラフィック負荷を集計して load/store のキューイング占有度(`unc_cxlcm_rxc_pack_buf` カウンタから得る)を各 RC に按分する。次に FlexBus RCHost Uncore セグメントへ移動し、待機(クレジット枯渇)サイクル `unc_m2p_rxc_cycles_ne` を分割する。続いて Host UncoreCHA セグメントの RPQ/WRQ 遅延(`unc_m_rpq_cycles_ne`・`unc_m_wpq_cycles_ne`)を各 CHA へ比例配分し、CHA 内では TOR で観測されたストールサイクルを LLC スライス-CCD 対応関係に基づいて分割する。最後に Core LLC→L2→LFB→L1D→SB の各オンコアパスセグメントに、CXL 起因のストールサイクルを比例配分しながら back-propagate する。 - **PFAnalyzer(遅延ベースのキューイング解析、Little's Law、§4.5)**: ネットワーク領域の delay-based queueing analysis [32, 36, 44] を応用し、Clos ネットワークの各ハードウェア(頂点)をソフトウェアスイッチとみなし、FCFS キュー(S3-FIFO の変種)としてモデル化する。各アーキテクチャモジュールの PMU が (a) ヒット/ミス頻度(HitCnt, MissCnt)と (b) データ応答時間(Delay)の 2 種のカウンタを持つという観察に基づき、Little's Law $L=\lambda \cdot W$ を用いて平均キュー長を推定する。L1D・L2・LLC ではヒットとミスの両方を含む拡張式 $L=\lambda_{hit} \cdot W_{hit} + \lambda_{miss} \cdot W_{miss}$ を用い(L1D/L2 では $W_{miss}$ にタグルックアップ時間 $W_{tag}$ を、LLC ではミス遅延そのものを用いる)、LFB と DIMM ではヒットのみを考慮する $L=\lambda_{hit} \cdot W_{hit}$ を用いる。DRd・RFO・HWPF パスそれぞれについて各コンポーネントのキュー長を推定し、キュー長が最大となるコンポーネント・パスを culprit(ボトルネックの原因)として特定する(Algorithm 1)。 - **PFMaterializer(スナップショット横断解析、§4.6)**: InfluxDB のような時系列データベースを内蔵し、スナップショットをタグ付きレコードとして蓄積する。CLI インタフェースを通じて Flux クエリへ変換し、時系列クラスタリング [29] によって類似ヒット分布を持つウィンドウへスナップショットを分割し、Holt-Winters 予測法などの古典的時系列解析(TSA)技術でトレンド・季節性・残差(異常)を探索する。Pearson 相関係数(`pearsonr()`)により、同一時間窓の他アプリケーションの mFlow/パスとの相関を検出できる。 ## 新規性 既存のプロファイリングツールは、プロセッサレベル(Intel VTune・AMD uProf による Top-Down Analysis)、メモリサブシステムレベル([13, 43, 80] のレイテンシ-帯域曲線ベンチマーク)、PCIe/インターコネクトレベル([55, 69, 86] のベンチマーキングフレームワーク)のいずれかに個別に特化しており、オンチップの非効率性をオフチップの CXL メモリアクセスに関連付けることができず、CXL フローがプロセッサをストールさせる、ローカルメモリ要求に head-of-line blocking を引き起こす、CXL リンク帯域を浪費するといった病理的シナリオを診断できない。PathFinder は、これら 3 レベルすべてを単一のシステムモデル(Clos ネットワーク)の下に統合し、伝統的なネットワークトラフィック解析技術(traceroute・reverse traceroute・delay-based queueing analysis・network snapshot)をホスト内部のマイクロアーキテクチャ解析へ転用した点が新規性である。§3 の PMU 探査で 232 種のカウンタを同定し(コア・CHA/LLC・アンコア・CXL デバイスの 4 部門)、これらが CXL.mem の 4 データパス(DRd・DWr→RFO・RFO・HW/SW PF)をエンドツーエンドで追跡できることを示した点も、既存研究にない貢献である。 ## 実験設定 - **ハードウェア環境**: (1) Intel Sapphire Rapids(SPR)デュアルソケットサーバ(Sub-NUMA Clustering 有効、Xeon Gold 6438Y+ × 2、DDR5 256GB、32コア 2.0GHz、LLC 60MB、L1D 48KB/L2 2MB、Intel Agilex I-Series ベースの CXL Type-3 デバイス 16GB DDR4、Linux 6.5 カーネル+CHA PMU パッチ)。(2) Intel Emerald Rapids(EMR)デュアルソケットサーバ(Xeon Gold 6530 × 2、DDR5 1536GB、32コア、LLC 160MB、L1D 48KB/L2 2MB、Micron CZ120 CXL Type-3 デバイス 256GB、Linux 6.15 カーネル)。両サーバとも per-core PMU・64 CHA PMU・IMC/M2PCIe PMU を搭載する。 - **ワークロード**: SPEC CPU 2017・PARSEC・SPLASH-2X・GAP・Redis・YCSB から 77 アプリケーション(Table 6、Appendix A.4)。 - **比較対象**: 論文自体は既存プロファイラとの定量比較実験は行わず、ローカルメモリ実行と CXL メモリ実行の PMU カウンタを直接比較する形で CXL.mem の影響を定量化する。 - **評価指標**: パイプラインストールサイクル数、データ応答待機サイクル、L1D/L2/LLC のヒット・ミス数、キューイング占有度・キュー長、CXL 帯域・レイテンシ、システムオーバーヘッド(CPU サイクル・メモリフットプリント)。 ## 実験結果 ### PMU 特性解析(§3、Figure 2-4) SPR サーバでローカルメモリと CXL メモリ実行を比較すると、CXL メモリは(a) Store Buffer のストールサイクルを RD+WR/WR-only ケースでそれぞれ平均 1.9倍・2.0倍に増加させ、(b) L1D で 2.1倍高いパイプラインストールサイクルと 1.4倍長い応答待機時間を、(c) L1D の DRd/RFO ヒットを平均 22.8% 減少させ、(d) L2 のコアストールサイクルを平均 2.7倍増加させる。 **Figure 2: コア性能カウンタのローカル/CXLメモリ比較** ![[_attachments/pathfinder-sigcomm25/fig02-core-pmu-local-vs-cxl.png]] (Figure 2. (a) Stall Buffer: 6アプリケーションでの読み書き混在/書き込みのみのケースでのストールサイクル(SB Stall Cycles)。(b) L1D Execution: CXLがResponse Wait Cycle・Pipeline Stall Cycleを増加させる。(c) L1D Operation: DRd+RFOのヒット/ミス・エビクション内訳。(d) Line Fill Buffer: LFBカウンタのStall/Hit挙動。(e) L2 Execution: コアストールサイクルとデータ応答。(f) L2 Operation: HW_PF/DRd/RFOのヒット・ミス内訳。Source: Figure 2.) CHA PMU(§3.3、Figure 3)では、CXL メモリアクセスによりコア LLC のストールサイクルが平均 2.1倍、DRd 応答時間が 1.8倍に増加し、LLC ヒットは DRd・RFO・HWPF でそれぞれ平均 46.5%・41.3%・62.2% 減少する一方、LLC ミスは 4.2倍・4.0倍・5.3倍に増加する。非 CXL ケースでは DRd・RFO・HWPF の 99.0% 超がローカル DIMM から供給されるのに対し、CXL ケースでは 38.4%・4.1%・49.2% のミスが cross-chiplet/socket リモートキャッシュのスヌーピングで直接解決されてから CXL DIMM に至る。 **Figure 3: CHA PMUのローカル/CXLメモリ比較** ![[_attachments/pathfinder-sigcomm25/fig03-cha-pmu-local-vs-cxl.png]] (Figure 3. (a) Core LLC Execution: LLCストールサイクル。(b) Core LLC Hit/Miss Breakdown: DRd/HWPF/RFO/DWrのヒット・ミス内訳。(c) Core LLC Miss Serve Target: MCFにおけるローカル/CXLミスの供給元(Local_Memory・SNC_LLC・SNC_Memory・Remote_LLC・Remote_Memory・CXL_Memory)の分布。(d)(e) CHA LLC Hit/Miss Occupancy: Y軸対数スケールでのオキュパンシー。(f) CHA LLC Operation: HW_PF/RFO/DRd/WBのヒット・ミス内訳。Source: Figure 3.) アンコア PMU(§3.4、Figure 4)では、IMC の RPQ/WPQ キューイングは CXL の場合ほとんど発生しない(CXL DIMM 自体がデバイス側コマンドキューを持つため)ことが分かり、CXL 専用ストリーム解析では IMC の影響を無視できる。ただし混在メモリストリーム下ではローカル DIMM 起因の IMC キューが CXL アクセスをブロックしうる。M2PCIe PMU により、同一プロファイリングサイクルあたりのロード/ストア量は CXL の場合ローカルより平均 36.7% 少ないことが分かる(CXL アクセスが低速なため)。 **Figure 4: アンコアPMUのローカル/CXLメモリ比較** ![[_attachments/pathfinder-sigcomm25/fig04-uncore-pmu-local-vs-cxl.png]] (Figure 4. (a) Queueing Occupancy: RPQ/WPQのオキュパンシー(X264・CAC・PAR・OMN・XZ・MCF)。(b) Load/Store Breakdown: X264・CAC・PARでのLD/ST内訳。Source: Figure 4.) これらの特性は EMR サーバ(§3.6、Appendix A.1、Figure 14-16)でも一貫して観察され、より大きな LLC を持つ EMR ではコアストールサイクルと L1D/L2/LLC ミスの増加幅が SPR より小さいものの、傾向自体は同一である(本 source ページでは Figure 14-16 は主要ケーススタディとの重複度が高いため図としては割愛し、数値知見のみを記載する。詳細は「出典検査」節参照)。 ### Case 1: パス分類(§5.2) PFBuilder は 649.fotonik3d_s において、コアレベルでは DRd がホットパスであり、アンコアレベルでは HWPF がアンコアアクセスの 59.3% を占め、CXL メモリヒットはローカル LLC ヒットの 8.1倍多く、HWPF パスが CXL メモリアクセスの 89.1% を占めることを示す。602.gcc_s の 2 つのスナップショットを比較すると、コア発行要求の総数(DRd+RFO+DWr のヒット合計)がスナップショット 2 で 5.8倍に増加し、その内訳は DRd がほぼ横ばい(25.9%→27.7%)である一方 RFO が 1.1%→69.0% へ急増しており、大量のデータが CXL メモリからロードされていることを示す(Table 7 に詳細な数値がある)。 ### Case 2: パイプラインストール分解(§5.3、Figure 6-7) fft アプリケーションの DRd パスのスタック遅延は L1D・LFB・L2・LLC・CHA・FlexBus+MC・CXL DIMM の 7 コンポーネントに 5.7%・0.0%・5.5%・3.9%・1.7%・42.7%・40.3% の比率で分布し、アンコアでの遅延が顕著である一方、raytrace は FlexBus・MC で 67.1% と最も偏る。back-propagation の効果として、CXL 起因のストールは DRd/RFO パスで FlexBus+MC から L1D へ向かうにつれ平均 74.5%/67.8% 減衰する(階層キャッシュによるローカリティ吸収)。BFS では FlexBus+MC 上の 353.5ns の HWPF ストールが L1D・L2 上でそれぞれ 209.8ns・179.46ns の DRd ストールに対応する一方、FREQ では同 92.2ns の HWPF ストールが L1D・L2 でわずか 13.4ns・0.7ns にしか対応せず、PFEstimator が L1D/L2 ハードウェアプリフェッチャの効果の違いを暗黙的に捉えられることを示す。 **Figure 6: CXL起因スタックサイクルの分解** ![[_attachments/pathfinder-sigcomm25/fig06-stall-cycle-breakdown.png]] (Figure 6. SB・L1D・LFB・L2・CHA/LLC・FlexBus+MC・CXL_DIMMの7コンポーネントにわたる(a) DRd・(b) RFO・(c) HW PF・(d) DWr各パスのスタック遅延分解(ns)を、fft・barnes・raytrace・freqmine・cc・bfsの6アプリケーションで示す。Source: Figure 6.) **Figure 7: CXLトラフィック負荷変化に対するパイプラインストールサイクル** ![[_attachments/pathfinder-sigcomm25/fig07-stall-vs-cxl-traffic-load.png]] (Figure 7. (a) SB・(b) L1D・(c) LFB・(d) L2・(e) Core LLC・(f) FlexBus+MC(DRd)の各コンポーネントで、CXLトラフィック負荷を20%から100%まで変化させた際のストール時間(ns)をWATER・VOL・RAY・BODYの4アプリケーションで示す。Source: Figure 7.) ### Case 3: ローカル vs CXL アクセス干渉(§5.4、Figure 8) 同一コア上にローカル mFlow と CXL mFlow を配置し、CXL トラフィック負荷を 20% から 100% へ変化させると、FlexBus と CHA でのキューイングは安定しているにもかかわらず、コア内の CXL 起因ストールは SB・L1D・LFB・L2・core LLC でそれぞれ 1.7倍・2.2倍・2.2倍・2.4倍・2.4倍に増加する。これは PFAnalyzer が FlexBus/CHA が輻輳していなくてもコア内部のキューイング増加を捕捉できることを示す。CXL 起因ストールの増加は L1D のローカリティを劣化させ、L2 での重いキューイングと長い L2 要求サービスレイテンシを引き起こし、コアのボトルネックが L1D 上の DRd から L2 上の DRd へシフトする。 **Figure 8: CXLトラフィック負荷変化に対するコンポーネントキュー長** ![[_attachments/pathfinder-sigcomm25/fig08-queue-length-vs-cxl-traffic-load.png]] (Figure 8. (a) L1D・(b) LFB・(c) L2(DRd)・(d) FlexBus+MC(DRd)の各コンポーネントでのキュー長(#)を、CXLトラフィック負荷20%〜100%に対してWATER・VOL・RAY・BODYの4アプリケーションで示す。Source: Figure 8.) ### Case 4: 並行 CXL アクセス輻輳(§5.5、Figure 9-10) CXL mFlow のトラフィックを 20% から 100% に増加させると、YCSB mFlow のスループットは平均 77.4% 低下する。すべての CXL mFlow は FlexBus+MC に集約されるため、PFEstimator は FlexBus+MC レイテンシの 4.3倍の増加を捉え、PFAnalyzer は FlexBus+MC の DRd・HWPF のキューイング度がそれぞれ 4.6倍・1.2倍に増加することを示す。CHA レイテンシも 1.6倍上昇し、CHA が CXL mFlow 間の干渉を完全には隠蔽できないこと、CXL メモリからの圧力が階層を上向きに伝播してコアコンポーネント性能に影響することが分かる。YCSB mFlow の LLC は CXL 起因ストール時間が 1.8倍、キューイング度が 3.4倍に増加する。CXL mFlow 同士は個々のコアでは交錯しないにもかかわらず、アンコアでの干渉増大がコアコンポーネントに間接的に影響する。SB・LFB・L2 の CXL 起因ストール時間はそれぞれ 2.1倍・2.9倍・1.8倍に増加し、L1D のキューイング度は 41.0% 低下しつつ mFlow のボトルネックが L1D 上の DRd から FlexBus+MC 上の HWPF へと段階的にシフトする。 **Figure 9: 並行CXL mFlowによるアプリケーション性能・スタックサイクルへの影響** ![[_attachments/pathfinder-sigcomm25/fig09-concurrent-cxl-mflow-throughput-stall.png]] (Figure 9. (a) Application Throughput・(b) SB・(c) L1D・(d) LFB・(e) L2・(f) Core LLC・(g) CHA latency(DRd)・(h) FlexBus+MC latency(DRd)を、並行CXLトラフィック負荷20%〜100%に対してYCSB-A/B/D/Fの4ワークロードで示す。Source: Figure 9.) **Figure 10: 並行CXL mFlowによるキュー長への影響** ![[_attachments/pathfinder-sigcomm25/fig10-concurrent-cxl-mflow-queue-length.png]] (Figure 10. (a) L1D・(b) LFB・(c) L2・(d) Core LLC・(e) FlexBus+MC(DRd)・(f) FlexBus+MC(HWPF)のキュー長(#)を、並行CXLトラフィック負荷20%〜100%に対してYCSB-A/B/D/Fの4ワークロードで示す。Source: Figure 10.) ### Case 5: CXL 帯域分割(§5.6、Figure 11) 4 MBW インスタンス(帯域 500/700/1000/3700 MB/s)と 4 GUPS インスタンス(650/1250/2200/2800 MB/s)の競合実験では、FlexBus+MC が飽和し、mFlow ごとの帯域劣化は一様でない(MBW-2 は 37.7% 低下、MBW-4 は 74.7% 低下)。CXL メモリアクセスレイテンシが 974.9ns・753.6ns まで増加すると深刻な FlexBus ブロッキングが発生し、PFAnalyzer は FlexBus での最大キュー長を検出する。CXL メモリ要求頻度とアプリケーションレベル報告帯域との Pearson 相関係数は 0.998 に達し、culprit path が FlexBus+MC で特定された場合、PFBuilder のリクエスト頻度レポートから並行 CXL mFlow 間の帯域配分を推定できる。 **Figure 11: 並行CXL mFlow間の帯域分割** ![[_attachments/pathfinder-sigcomm25/fig11-cxl-bandwidth-partition.png]] (Figure 11. (a) mFlows bandwidth: MBW/GUPS 4インスタンスでのFlexBus飽和有無別の帯域(MB/s)。(b) CXL BW and request frequency: CXLリクエスト数と実行時帯域の関係(4MBW・4GUPS)。Source: Figure 11.) ### Case 6: データローカリティ(§5.7、Figure 12) PFMaterializer はスナップショット系列からデータローカリティの時間変化を報告する。503.bwaves_r と 519.lbm_r(ローカルメモリアクセス)を co-locate した場合、554.roms_r(CXL メモリアクセス)を co-locate した場合と比較して LLC ミスが 20.6% 減少し、503.bwaves_r が 519.lbm_r との実行時により親和的であることを示す。 **Figure 12: 503.bwaves_rのデータローカリティ変化** ![[_attachments/pathfinder-sigcomm25/fig12-data-locality-changes.png]] (Figure 12. LD L1D Hit・LD LFB Hit・L2 Access・LLC Access・HW PF LLC Hit・HW PF CXL Hitの各ヒット数(対数スケール)の時系列変化を、(a) 519.lbm_r起動時、(b) 554.roms_r起動時、(c) 519.lbm_r・505.mcf_r・554.roms_rを組み合わせた複数アプリケーション同時実行時、について示す。Source: Figure 12.) ### Case 7: PathFinder を用いた性能最適化(§5.8、Figure 13) TPP [79] を有効化すると、(a) YCSB-C(Zipf アクセスパターン、ローカル/CXL 比 4:1)のクエリレイテンシが 2.5% 減少、(b) GUPS(24GB ホットセット/72GB 総ワーキングセット、1:1 読み書き比、90% ホットセットアクセス確率)のスループットが 3.0倍向上、(c) 649.fotonik3d_s の実行時間が 14.3% 短縮する(ローカル/CXL 比 2:1)。PFBuilder のトレースでは、GUPS で DRd/RFO/HWPF のローカルメモリヒットがそれぞれ 7.4倍・1.7倍・3.3倍に増加し、対応する CXL メモリヒット数は 87.2%/93.4%/87.7% 減少する。PFEstimator の分析では、TPP が CHA アクセスレイテンシを削減し(FlexBus+MC の DRd/RFO/HWPF レイテンシがそれぞれ 78.6%/83.5%/79.1% 減少)、アンコアサービスレイテンシが 82.9%/85.8%/88.0% 削減される。さらに TPP+Colloid [97] の動的組み合わせを検証し、PathFinder(PFBuilder の CHA ミス率+PFEstimator のローカル/CXL レイテンシ)を Colloid の固定 DRd レイテンシの代わりに用いることで GUPS スループットが 1.1倍向上することを示す。 **Figure 13: TPP有効化前後の比較** ![[_attachments/pathfinder-sigcomm25/fig13-tpp-optimization-comparison.png]] (Figure 13. (a) Hit event: DRd-L/RFO-L/HWPF-L(ローカル)・DRd-C/RFO-C/HWPF-C(CXL)・M2P-LD/M2P-ST(M2PCIe)のヒット数を、YCSB-C・649.fotonik3d_s(FOTS)・GUPSについてTPP有効/無効で比較(対数スケール)。(b) Stall data path: CHA-DRd/RFO/HWPF/DWr・FMC-DRd/RFO/HWPFのスタック時間(ns、対数スケール)をTPP有効/無効で比較。Source: Figure 13.) ### システムオーバーヘッド(§5.9) 全ワークロードを通じて、PathFinder は平均で 1.3% の CPU サイクルと 38MB のメモリを消費し、プロファイル対象アプリケーションの実行への影響は軽微である。 ## 考察 PMU 特性解析(§3)から、CHA・M2PCIe・CXL PMU は CXL 読み書きメモリトラフィックのグラウンドトゥルース情報を提供しアンコアレベルでの効果を捉える一方、コア PMU は DRd・DWr・RFO・HW/SW PF という異なるパスの CXL メモリ特性をアンコアからコアプライベートキャッシュ、プロセッサパイプラインまで分析可能にする、という役割分担が明らかになった。back-propagation によるスタックサイクル分解(PFEstimator)は、階層キャッシュによってアンコアからコアに向かって CXL 起因のストールが漸減する現象(ローカリティ)を定量的に捉えられる点で、単純に「ミス発生先の比率で按分する」既存の粗い手法([95] が不正確だと指摘する手法)より優れている。Little's Law に基づく PFAnalyzer は、FlexBus/CHA といったアンコア共有資源が輻輳していない場合でも、コア内部の隠れたキューイング増加を検出できる点が、単一レイヤーのプロファイラにはない強みである。 ## 強み / 弱点・課題 - **強み**: (1) コア・CHA・アンコア・CXL デバイスという 4 階層すべてを単一の Clos ネットワークモデルに統合し、既存研究にないエンドツーエンド解析を実現した。(2) 既存ハードウェア PMU のみに依拠し、命令挿入や再コンパイルを必要としない軽量設計(オーバーヘッド 1.3% CPU / 38MB メモリ)。(3) traceroute・reverse traceroute・Little's Law キューイング解析といったネットワーク領域の確立された解析技術を、ホスト内部のマイクロアーキテクチャ解析に転用するという方法論的橋渡しが独自性を持つ。(4) SPR と EMR という異なる世代のプロセッサで一貫した PMU 挙動を確認し(§3.6)、手法の一般性を実証している。(5) TPP・Colloid という既存のページ配置最適化システムと組み合わせ、実運用での性能改善(GUPS スループット 1.1倍)を示した点で、単なる診断ツールを超えた実用性を示す。 - **弱点・課題(§5.9 Limitation より)**: (1) RFO・HWPF リクエスト専用の PMU カウンタがコア内に存在しないため、PFBuilder・PFEstimator は L1D・LFB レベルで RFO・DWr タイプのリクエストを監視できず、L2 の RFO カウンタは demand と prefetch の RFO を区別できない。(2) コア PMU に依拠する部分では、L1D・LFB・L2・LLC のスタックサイクルは demand load リクエストのみが対象で、アクセスタイプ別にさらに分解できない。将来のより高度な PMU 機能でこれらの制約は解消されうる、と著者らは述べる。(3) 現行の CXL DIMM(AMD CZ120/CZ122、Smart Modular CMM-E3S、Samsung CMM-B/CMM-H)は CXL 仕様 3.0/3.1 が定義する QoS テレメトリ(light/optimal/moderate/severe overload)に未対応であり、この機能の評価は将来課題として残されている(§3.5)。