> [!abstract] 概要(Abstractの日本語訳) > ホストネットワークは、プロセッサ・メモリ・周辺機器のインターコネクトを統合し、ホスト内でのデータ転送を可能にする。大規模本番データセンターを対象とした近年の複数の研究は、ホストネットワーク内の競合がエンドツーエンドのアプリケーション性能に大きな影響を与えうることを示している。本論文の目標は、ホストネットワーク内のこのような競合について深い理解を構築することである。 > 我々は、ホストネットワークを研究するための概念的抽象化であるドメインごとのクレジットベースフロー制御(domain-by-domain credit-based flow control)を提示する。我々は、ホストネットワークが異なる複数のドメイン(ホストネットワーク内のサブネットワーク)にわたってフロー制御を行っていることを示す。異なるアプリケーションは異なるドメインを通過しうるため、ホストネットワーク内の競合に対して異なる性能劣化を観測しうる。このレンズを通してホストネットワークを探求することで、(1) 既存研究で観測されたホストネットワーク内の競合とそのネットワークアプリケーションへの影響をほぼ正確に説明でき、(2) ホストネットワーク内の競合について、これまで報告されてこなかった新たなレジームを発見できる。 > より広く言えば、我々の研究は、ホストネットワーク内の競合が単にホストネットワーク資源の不足によるものではなく、むしろホストネットワーク内のプロセッサ・メモリ・周辺機器インターコネクト間の相互作用の悪さに起因することを明らかにする。さらに、ホストネットワーク内の競合が持つ意味合いは、これまでの研究が扱ってきたネットワークアプリケーションという文脈よりもはるかに広範囲に及ぶ。すなわち、我々の観測結果はすべて、全アプリケーションが単一ホスト内に収まっている場合でも成立する。 ## 論文情報 - タイトル: Understanding the Host Network - 著者・所属: Midhul Vuppalapati([[Cornell University]])、Saksham Agarwal([[Cornell University]])、Henry N. Schuh([[University of Washington]])、Baris Kasikci([[University of Washington]])、Arvind Krishnamurthy([[University of Washington]])、Rachit Agarwal([[Cornell University]]) - 媒体: ACM SIGCOMM 2024 Conference(ACM SIGCOMM '24)、2024年8月4〜8日、Sydney, NSW, Australia。ACM刊、全14ページ。 - DOI: [https://doi.org/10.1145/3651890.3672271](https://doi.org/10.1145/3651890.3672271) - ACM ISBN: 979-8-4007-0614-1/24/08 - コード・テクニカルレポート: [https://github.com/host-architecture/understanding-the-host-network](https://github.com/host-architecture/understanding-the-host-network) ## 概要 ホストネットワーク(プロセッサ・メモリ・周辺機器インターコネクトを統合しホスト内のデータ転送を担う経路)における競合を、ドメインごとのクレジットベースフロー制御という概念的抽象化を通じて解明する研究。既存研究(Google のホストインターコネクト輻輳研究 [1, 2]、Alibaba Pangu [42]、Hostping [44] 等)が報告した「P2M(周辺機器→メモリ)トラフィックがメモリ帯域飽和時にC2M(コンピュート→メモリ)トラフィックを圧迫する」現象(赤レジーム)を再現・説明するだけでなく、メモリ帯域が飽和していない段階でC2Mアプリのみが劣化しP2Mアプリが無傷という、これまで報告されていなかった逆方向の現象(青レジーム)を新たに発見する。 ## 問題設定 - 対象: 単一ソケット内のホストネットワーク(コア、L1/L2/LLCキャッシュ、Caching and Home Agent (CHA)、Integrated IO controller (IIO)、Memory Controller (MC)、DRAM)における、コンピュート由来(C2M: compute-to-memory)トラフィックと周辺機器由来(P2M: peripheral-to-memory)トラフィックの相互作用。 - 前提: C2M/P2Mリクエストがキャッシュ階層の全レベルでミスするシナリオに焦点を当てる。 - 使用ハードウェア: Intel Ice Lake(Xeon Platinum 8362、32コア@2.8GHz、LLC 48MB、DRAM 4×3200MHz DDR4で102.4GB/s、PCIe 8×PM173X NVMeで32GB/s)と Intel Cascade Lake(Xeon Gold 6234、8コア@3.3GHz、LLC 24MB、DRAM 2×2933MHz DDR4で46.9GB/s、PCIe 4×P5800X NVMeで16GB/s)の2種のサーバ(いずれも単一ソケット)。 **Table 1: 実験に用いた2台のサーバのハードウェア構成(単一ソケットあたりの値。DRAM・PCIe帯域は理論最大値)。** ![[_attachments/Understanding-the-Host-Network/table01-hardware-config.png]] (Table 1. Ice Lake は32コア/DRAM帯域102.4GB/s/PCIe帯域32GB/s、Cascade Lake は8コア/DRAM帯域46.9GB/s/PCIe帯域16GB/sで、コア数対メモリ帯域比が異なる2構成。Source: Adapted from Table 1.) ## 提案手法 ### ドメインごとのクレジットベースフロー制御(domain-by-domain credit-based flow control) - **概念**: ホストネットワークを複数の「ドメイン」(ホストネットワーク内のサブネットワーク)に論理的に分解し、各ドメインが独立したクレジットベースフロー制御を行うとみなす抽象化。各ドメインの送信側にはクレジットが割り当てられ、1リクエストの送信につき1クレジットを消費し、ドメインの受信側でリクエストの受信が確認されるとクレジットが補充される。これは古典的な計算機ネットワークの2つのフロー制御機構(TCP等のエンドツーエンド型と、ATM/PFC対応RDMA等のホップバイホップ型)を一般化したものと位置づけられる——前者はパス全体が単一ドメインである特殊ケース、後者は経路上の各ホップが1ドメインである特殊ケースに相当する。 - **アーキテクチャ**: ホストアーキテクチャは、プライベートL1/L2キャッシュを持つコア群、LLC、CHA(LLCとメモリを抽象化しキャッシュコヒーレンシを維持)、IIO(周辺機器がPCIe経由で接続)、MC(DRAMへの読み書きを制御)から構成される。 **Figure 4: ホストネットワークアーキテクチャとC2M/P2Mのデータパス** ![[_attachments/Understanding-the-Host-Network/fig04-host-network-architecture.png]] (Figure 4. コア(L1/L2キャッシュ付き)・LFB・CHA/LLC・IIO・MC(RPQ/WPQ)・DRAM(DRAM Banks)の接続関係と、C2Mデータパス(①L1ミス時にLFBへ登録→②L2へ→③CHA/LLCへ→④MCのRPQ/WPQへキューイング)、P2Mデータパス(①周辺機器がIIOへDMAリクエスト→②IIOがCHAへ転送)のホップ順序を示す。Source: Adapted from Figure 4.) - **4つの主要ドメイン**: 各リクエストは発生源(コア/周辺機器)と種別(読み/書き)に応じて異なるドメイン集合を通過する。ボトルネックとなりうる4つの主要ドメインは以下の通り。 - **C2M-Readドメイン**: LFB(Line Fill Buffer)からDRAMまでの全ホップにまたがる。クレジットはLFBで割り当てられ、DRAMからサービスされデータがLFBに返るまで解放されない(重複メモリリクエスト防止のため)。 - **P2M-Readドメイン**: IIOからDRAMまでの全ホップにまたがる。PCIe読み取りが non-posted transaction であるため、DRAMからサービスされ完了通知が発行されるまでIIOはクレジットを保持し続ける。 - **C2M-Writeドメイン**: LFBからCHAまでの単一ホップのみ(MCを含まない。書き込みはDRAMへ非同期にサービスされるため)。 - **P2M-Writeドメイン**: IIOからMCまでの2ホップ(MCを含む)。 **Figure 5: ドメインごとのクレジットベースフロー制御 — C2M/P2M読み書き4パターンにおける独立ドメイン** ![[_attachments/Understanding-the-Host-Network/fig05-domain-credit-flow-control.png]] (Figure 5. C2M-Read domain(LFB↔DRAM、黄色ノードはLFB)・C2M-Write domain(LFB↔CHA)・P2M-Read domain(IIO↔DRAM、黄色ノードはIIO)・P2M-Write domain(IIO↔MC)の4象限を色分けして図示。各ドメインが通過するホップ数(=ドメインレイテンシ)とクレジット数(黄色ノードで律速)が異なることを示す。Source: Adapted from Figure 5.) - **スループット上限**: 任意のドメインの最大スループット $T$ は $T \leq C \times 64 / L$ で上界が与えられる。ここで $C$ はそのドメインの送信側が持つハードウェア固有のクレジット数(キャッシュライン単位)、64はキャッシュラインサイズ(バイト)、$L$ はドメイン内の全ホップを通過するのに要するレイテンシである。あるC2M/P2Mアプリのエンドツーエンドスループットは、そのデータパス上の全ドメインにおけるスループットの最小値で決まる。 - **リバースエンジニアリングによる特性測定**: Intel の uncore performance monitoring counters を用いて、各ノードの平均キュー/バッファ占有率($O$)と平均リクエスト到着率($R$)を測定し、Little's law($L = O/R$)で平均レイテンシを算出する測定手法を用いて、各ドメインのクレジット数・無負荷時レイテンシをリバースエンジニアリングした。実測の結果、C2M-Read/C2M-Writeドメインのクレジット数はLFBサイズ(10〜12キャッシュライン)、P2M-Writeドメインのクレジット数はIIO書き込みバッファサイズ(約92キャッシュライン)、P2M-Readドメインのクレジット数はIIO読み取りバッファサイズ(下限164キャッシュライン以上)で律速される。無負荷時ドメインレイテンシは、C2M-Readで約70ns、C2M-Writeで約10ns、P2M-Writeで約300nsと測定された(§4.2、Figure 6)。 **Figure 6: ドメインとドメイン別特性のエビデンス** ![[_attachments/Understanding-the-Host-Network/fig06-domain-evidence-latency.png]] (Figure 6. (a) LFBレイテンシとCHA→DRAM読み取りレイテンシがC2Mコア数増加に対しほぼ完全に一致して増加し、C2M-ReadドメインがDRAMまでの全ホップを含むことを裏付ける。(b) LFBレイテンシとCHA→MC書き込みレイテンシの比較から、C2M-WriteドメインがMCを含まないことを示す。(c)(d) IIOレイテンシとCHA→MC書き込みレイテンシの推移が一致し、P2M-WriteドメインがMCを含むことを示す。Source: Adapted from Figure 6.) ### 定量的検証のための解析式 - **読み取りドメインレイテンシの式**($L_m^{read} = \text{Constant}_{read} + QD_{read}$): $QD_{read}$ は Switching Delay(書き込み→読み取り切替遅延)・Write Head-of-Line blocking(チャネルが書き込みモード中の待ち)・Read Head-of-Line blocking(RPQ内の先行リクエスト待ち)・Top-of-queue delay(activate/precharge操作待ち)の4成分の和として表される。 **Figure 9: 読み取りドメインレイテンシの構成要素** ![[_attachments/Understanding-the-Host-Network/fig09-read-domain-latency-formula.png]] (Figure 9. $QD_{read}=O_{RPQ}\cdot\frac{\#switches}{lines_{read}}\cdot t_{WTR}$(Switching Delay)+ $O_{RPQ}\cdot\frac{lines_{written}}{lines_{read}}\cdot t_{Trans}$(Write HoL blocking)+ $(O_{RPQ}-1)\cdot t_{Trans}$(Read HoL blocking)+ $\frac{\#ACT_{read}}{lines_{read}}\cdot t_{ACT}+\frac{\#PRE^{conflict}_{read}}{lines_{read}}\cdot t_{PRE}$(Top-of-queue delay)の4項からなる式。C2M-Read・P2M-Read両ドメインに適用可能。Source: Adapted from Figure 9.) - **書き込みドメインレイテンシの式**($L_m^{write} = \text{Constant}_{write} + AD_{write}$): $AD_{write}$ はWPQが満杯になる確率($P_{fill}^{WPQ}$)と満杯時の平均待ち時間($X_{write}$)の積で表され、$X_{write}$ は読み取り式と双対の4成分(Switching Delay・Read HoL blocking・Write HoL blocking・Top-of-queue delay)からなる。 **Figure 10: 書き込みドメインレイテンシの構成要素** ![[_attachments/Understanding-the-Host-Network/fig10-write-domain-latency-formula.png]] (Figure 10. $AD_{write}=P_{fill}^{WPQ}\cdot X_{write}$、$X_{write}=N_{waiting}\cdot\frac{\#switches}{lines_{written}}\cdot t_{RTW}$(Switching Delay)+ $N_{waiting}\cdot\frac{lines_{read}}{lines_{written}}\cdot t_{Trans}$(Read HoL blocking)+ $(N_{waiting}-1)\cdot t_{Trans}$(Write HoL blocking)+ Top-of-queue delay項。C2M書き込みは待たずに完了するためC2M-Writeドメインのレイテンシ膨張は定数として扱う。Source: Adapted from Figure 10.) - **入力パラメータ**(Table 2): $P_{fill}^{WPQ}$(WPQ満杯確率)・$N_{waiting}$(WPQ admission待ちの書き込みリクエスト数)・$\#switches$(読み書きモード切替回数)・$lines_{read/write}$(読み/書きキャッシュライン数)・$O_{RPQ}$(平均RPQ占有率)・$PRE^{conflict}_{read/write}$(行競合によるprecharge回数)・$ACT_{read/write}$(activate回数)は、いずれもIntelのuncore performance countersから測定・導出可能。 **Table 2: 解析式への入力パラメータ** ![[_attachments/Understanding-the-Host-Network/table02-formula-inputs.png]] (Table 2. §6.1で議論する解析式の各入力記号とその意味の一覧。Source: Adapted from Table 2.) ## 新規性 既存の計算機アーキテクチャ研究は個々のインターコネクト(プロセッサ・メモリ・周辺機器)の挙動に焦点を当ててきたが、これらインターコネクト間の相互作用がホストネットワーク内の競合をどう引き起こすかは扱ってこなかった。一方、既存の計算機ネットワーキング研究([1, 2, 42, 44, 55])はホストネットワーク内の競合がエンドツーエンドプロトコルの挙動(パケットキューイング・ドロップ)に与える影響を扱うが、競合そのものの根本原因の特定はしてこなかった。本論文は、ドメインごとのクレジットベースフロー制御という単一の概念的レンズによって両分野を橋渡しし、既存研究が報告した現象(赤レジーム: P2Mトラフィックがメモリ帯域飽和時にC2Mを圧迫する)をほぼ正確に説明するだけでなく、これまで報告されていなかった逆方向の現象(青レジーム: メモリ帯域未飽和でもC2Mのみが劣化しP2Mは無傷)を新たに発見する点で新規性を持つ。さらに、既存研究がネットワークアプリケーション(P2Mトラフィック)への影響に着目していたのに対し、本研究は全アプリケーションが単一ホスト内に収まる場合でも同じ現象が生じることを示し、影響範囲がネットワークプロトコルの文脈を超えることを明らかにした。 ## 実験設定 - **実験環境**: Table 1のIce Lake / Cascade Lakeサーバ、単一ソケット。各DRAMモジュールは別チャネルに接続され、単純な逐次読み取りマイクロベンチマークで理論最大メモリ帯域の90%超を達成できる構成。 - **C2Mアプリ**: (1) Redis(sharding方式のマルチコアデプロイ、YCSB-C 100%読み取りワークロード、サーバコアあたり100万key-value・値サイズ1KBでLLCを超過、キャッシュミス率>95%)。(2) GAPBS(GAP Benchmark Suite)のPageRankワークロード( $2^{25}$ ノード・次数16のランダムグラフ、約5GBのメモリフットプリント)。GAPBSはRedisよりメモリ帯域集約的で計算が軽い。 - **P2Mアプリ**: FIO(8MBリクエストサイズの逐次ストレージ読み取り。大規模分散データストアのストレージノードを想定)。読み取りはストレージデバイスからホストメモリへのDMA書き込み(P2M書き込みトラフィック)を生成する。DDIOはこのワークロードに対して有効でない(アプリケーションバッファがDDIOの利用可能なキャッシュ容量に収まらないため)。 - **軽量ワークロード(§2.2)**: STREAM改変版でC2Mトラフィックを生成(C2M-Read: 1GBバッファへの64バイトAVX512逐次読み取りで100%メモリ読み取り。C2M-ReadWrite: 逐次書き込みで50%読み取り/50%書き込み)。FIOでP2Mトラフィックを生成(P2M-Write: 100%ストレージ読み取り→100%メモリ書き込み。P2M-Read: 100%ストレージ書き込み→100%メモリ読み取り)。この2×2の組み合わせを「4つの象限(quadrants)」と呼ぶ。 - **比較対象**: 各アプリを単独実行した場合(isolated)と、C2M/P2Mを同居させた場合(colocated)のスループットを比較。評価指標はスループット劣化度(isolated / colocated のスループット比。GAPBSは実行時間の比)。 ## 実験結果 ### 実アプリでの新現象(青レジーム)の再現(§2.1) C2M(Redis/GAPBS)とP2M(FIO)を同居させると、コアとPCIe帯域は分離されメモリ帯域も飽和していないにもかかわらず、C2Mアプリのみが劣化しP2Mアプリは無傷という現象が観測された。 **Figure 1: ホストネットワーク内競合の新現象 — C2Mが劣化しP2Mは無傷** ![[_attachments/Understanding-the-Host-Network/fig01-c2m-p2m-colocation-degradation.png]] (Figure 1. (a) Redis(C2M)とFIO(P2M)同居時、Redisは1.25〜1.32倍のスループット劣化を示す一方FIOは無傷。(b) GAPBS(C2M)は1.28〜1.98倍劣化しFIOは無傷。(c)(d) この劣化はメモリ帯域利用率が理論最大の33〜53%(Redis時)にとどまり飽和曲線が横ばいになっていない段階で発生する。Source: Adapted from Figure 1.) DDIO(Intel Data Direct I/O)を有効化すると、この劣化がさらに悪化する意外な結果も得られた。C2Mワークロードは単独実行時点で既にキャッシュミス率が約100%であり理論上はDDIOによるキャッシュ追い出しの影響を受けないはずだが、著者らはこの現象の説明を持ち合わせていない。 **Figure 2: DDIO有効化がキャッシュに収まらないワーキングセットで劣化を悪化させる** ![[_attachments/Understanding-the-Host-Network/fig02-ddio-worsens-degradation.png]] (Figure 2. Cascade LakeでDDIO on/offを比較すると、DDIO onの方がC2M(Redis/GAPBS)の劣化がDDIO offより大きい。P2M(FIO)は単独実行時点でDDIOの効果を受けない(バッファがキャッシュに収まらないため)ワークロードであるにもかかわらず、同居時のC2Mへの影響はDDIO on/offで異なる。Source: Adapted from Figure 2.) この現象は、Ice Lake/Cascade Lakeという異なる世代のプロセッサ、異なるコア対メモリ帯域比、プリフェッチ有無、DDIO有無の組み合わせで再現性が確認された。 ### 青レジームと赤レジームの体系的分類(§2.2) C2M/P2Mの読み書きの組み合わせ(4象限)ごとに、STREAM/FIOの軽量ワークロードでDDIO・プリフェッチを無効化して測定した結果、2つのレジームに分類された。 **Figure 3: 4象限にわたる青レジームと赤レジーム** ![[_attachments/Understanding-the-Host-Network/fig03-blue-red-regimes-quadrants.png]] (Figure 3. 象限1(C2M-Read, P2M-Write)・象限2(C2M-Read, P2M-Read)・象限4(C2M-ReadWrite, P2M-Read)は青レジーム(C2Mのみ劣化、水色背景)。象限3(C2M-ReadWrite, P2M-Write)は、C2Mコア数2以下では青レジーム的挙動だが、3コア以上でメモリ帯域が飽和すると赤レジーム(両方劣化、桃色背景)に転じる。Source: Adapted from Figure 3.) - **青レジーム**: C2Mスループットが劣化する一方P2Mスループットは劣化しない。象限1では1.2〜1.7倍のC2M劣化がメモリ帯域未飽和の段階(C2M単一コアの時点)から発生し、負荷増加とともに悪化する。 - **赤レジーム**: C2M・P2M両方のスループットが劣化する。象限3で3コア以上・メモリ帯域飽和後に、C2Mトラフィックがますます大きなメモリ帯域シェアを取りP2Mを antagonize する挙動が観測され、これは既存研究([1, 42])が報告した現象と一致する。ただしP2Mトラフィックは高負荷時(5〜6コア)でも完全には枯渇せず、C2M/P2Mのメモリ帯域シェアが相対的に安定化する新知見も得られた。 ### ネットワーキングケーススタディへの一般化(§2.3) 局所ストレージ由来のP2Mトラフィックの代わりにNIC由来のP2Mトラフィックを用い、カーネル内(DCTCP)およびハードウェアオフロード(RoCE/PFC)のトランスポートで同じ青・赤レジームの傾向を確認した(詳細な測定値はテクニカルレポート [68] に記載)。RoCE/PFCでは赤レジームでスループットが劣化する一方、青レジームではRoCE/PFCスループットは無傷でC2Mアプリのみが大きく劣化する。DCTCPでは両レジームでネットワークアプリの性能が劣化するが、これはデータコピー処理由来のC2Mトラフィックも同時に発生するためで、青レジームではC2M劣化がCPUボトルネックとなりDCTCPのフロー制御が働いて負荷が下がる一方、赤レジームではパケットドロップまで輻輳シグナルが送信元に返らずさらなる劣化・レイテンシ膨張・分離性違反(既存研究 [1, 2] が指摘)を招く。 ### 青レジームの根本原因(§5.1、象限1) - **C2M劣化の原因**: C2Mワークロードは単独実行時点でLFBクレジットを完全に使い切っている(1コアが3GHzなら0.3ns間隔で命令を発行でき、これはC2M-Readドメインの最小レイテンシより2桁以上小さいため)。したがってドメインレイテンシがわずかでも増加すればスループットが劣化する。P2M同居時、MCでのキューイング(DRAMがC2M-Readドメインに含まれるため)によりドメインレイテンシが1.26〜1.8倍増加する。 **Figure 7: 象限1(C2M-Read, P2M-Write)理解のための結果** ![[_attachments/Understanding-the-Host-Network/fig07-quadrant1-analysis.png]] (Figure 7. (a) C2Mレイテンシ(LFBレイテンシ)はP2M同居時に無しの場合より一貫して高い。(b) RPQ占有率もP2M同居時に増加。(c) 行ミス率はP2M同居時に最大4倍まで増加(C2M/P2Mが異なるアドレス空間にアクセスし行局所性を損なうため)。(d) バンク負荷偏差(最大/平均)は1.5倍以上が50〜70%のサンプル、2倍以上が13〜22%のサンプルで観測され、メモリチャネルアイドル時でもバンク処理待ちでブロックされうる。(e) P2Mレイテンシ(IIOレイテンシ)はP2M-Writeドメインの遅延なしにほぼ横ばい。(f) WPQが満杯になる時間割合は1コア時ほぼゼロ、増加しても30%未満。(g) IIOクレジット使用量は上限(観測値と上限線)に対し余裕があり続ける。Source: Adapted from Figure 7.) - **行ミス率とバンク負荷不均衡の複合効果**: MCでのキューイングはメモリ帯域飽和よりずっと前に発生する。これは(1) 行ミス(row miss)による処理遅延と(2) バンク間の負荷不均衡の組み合わせによる。$N_b$ バンクに完全に負荷分散されていれば $t_{Proc}/N_b < t_{Trans}$(実測値 $t_{Proc}\approx45ns$、$N_b=32$、$t_{Trans}=2.73ns$)を満たしバンク処理遅延はチャネル転送に隠蔽できるはずだが、静的ハッシュ関数によるアドレス→バンクマッピングは完全な負荷分散を保証しないため、チャネル容量(メモリ帯域)が未飽和でもバンク処理待ちによるブロッキングが生じる。 - **P2Mが劣化しない理由**: (1) P2M-Writeドメインは書き込みが非同期にサービスされるためDRAM実行レイテンシを含まず、MC書き込みキュー(WPQ)が満杯になったときのみレイテンシが増加する——1コアC2M同居時はWPQ満杯時間がほぼゼロで、C2Mコア数増加でも25ns未満の増加にとどまる。(2) P2Mワークロードは単独実行時点でドメインクレジットが余っている(無負荷時P2M-Writeレイテンシ約300nsに対し、PCIe帯域約14GB/s飽和には約65クレジットが必要で、利用可能な約92クレジットを下回る)ため、レイテンシがある程度増加してもin-flightリクエスト数を維持でき、スループット劣化に至らない。 ### 赤レジームの根本原因(§5.2、象限3) - **2つの新現象**: メモリ帯域飽和後(3コア以上)、(1) 3〜4コアでC2MがP2Mを antagonize する(C2M劣化が減りP2M劣化が急増)、(2) 4コア超でP2M劣化の増加ペースが鈍化する、という2つの新現象が観測された。 **Figure 8: 象限3(C2M-ReadWrite, P2M-Write)理解のための結果** ![[_attachments/Understanding-the-Host-Network/fig08-quadrant3-analysis.png]] (Figure 8. (a) C2Mレイテンシ、(b) RPQ占有率(4コア超で飽和しCHAからのバックプレッシャーを示唆)、(c) 行ミス率、(d) P2Mレイテンシ(3コア以降急増)。(e) WPQ満杯時間割合は3コアで75%、4コア以上でほぼ100%。(f) IIOクレジット使用量は上限に近づく。Source: Adapted from Figure 8.) - **MCからのバックプレッシャー**: メモリ帯域飽和後、MC書き込みキューが持続的に満杯になり(3コアで75%、4コア以上でほぼ常時)、CHAでの書き込みバックログを引き起こす。P2M-WriteドメインはMCを含むためこのバックプレッシャーの影響を受けレイテンシが1.5倍増加しスループットが大きく劣化するが、C2M-WriteドメインはMCを含まないため影響を受けず、C2Mワークロード(C2M-ReadWrite)はC2M-Readドメインレイテンシ(約12%増)のみで律速される。これによりC2Mのメモリ帯域シェアが増えP2Mのシェアが減る。 - **CHAからのバックプレッシャー**: 4コア超でCHAのバッファリング資源が限界に達すると、CHAへのリクエスト受け入れ自体が遅延し、これはC2M・P2M両ドメインに影響する(RPQ占有率が4コア超で頭打ちになりCHAでのブロッキングを示唆)。5〜6コアではC2M・P2M両方のドメインレイテンシがほぼ同等(約50ns)増加し、メモリ帯域シェアが相対的に安定化する。 ### 解析式による定量的検証(§6) MC(読み取り)・CHA(書き込み)でのキューイング遅延に着目した解析式を、象限1・2・4のC2Mスループット推定に適用した結果、全データ点で誤差10%以内を達成した。象限3では4コア以下で誤差10%以内だが、4コア超ではCHA admission delay(式が捕捉していないCHAバッファ満杯時の受け入れ遅延)により誤差が拡大する。CHA admission delayの実測値を式に加算すると、全データ点で誤差10%未満に収まった。 **Figure 11: 解析式の精度** ![[_attachments/Understanding-the-Host-Network/fig11-formula-accuracy-error.png]] (Figure 11. (上) 象限1・2・4のC2Mスループット推定誤差はいずれの点も±10%以内。(下) 象限3では、CHA admission delayを加算しない式(点線)は5〜6コアで誤差が30%近くまで拡大するが、加算した式(実線)は全点で10%以内に収まる。Source: Adapted from Figure 11.) **Figure 12: 解析式構成要素の内訳** ![[_attachments/Understanding-the-Host-Network/fig12-formula-component-breakdown.png]] (Figure 12. (a)象限1・(b)象限2・(c)象限4では、C2Mコア数1ではWrite HoL blockingが支配的、コア数増加でRead HoLも増加。象限2はRead HoL比率が高くWrite HoLは存在しない(書き込みが無いため)。(d)(e)象限3では、C2M/P2Mともに4コアまではWrite HoLが支配的だが、それ以降はCHA Admission Delayが支配的成分になる。Source: Adapted from Figure 12.) ## 考察 - **赤レジームは新しくない、青レジームが新しい**: 既存研究([1, 42, 44]等)が報告してきた現象は、本論文の分類では赤レジームに相当する。本論文最大の貢献は、メモリ帯域が未飽和の段階でC2Mのみが劣化しP2Mが無傷という逆方向の青レジームを発見し、その根本原因(ドメインクレジットの完全利用とドメインレイテンシの微小な膨張への感度の違い)を説明したことにある。 - **競合の本質は資源不足ではなく相互作用**: C2M-Writeドメインの範囲がMCを含まない一方P2M-Writeドメインは含む、C2M-Readドメインの無負荷レイテンシが約70nsと極めて短いためわずかな遅延にも敏感、といったドメイン設計上の非対称性が、資源(メモリ帯域・PCIe帯域)に余裕があっても性能劣化を引き起こす。 - **単一ホスト内でも影響が生じる**: 本研究の全観測結果は、ネットワーク越しの転送を一切介さずローカルストレージのみで再現されており、ホストネットワーク内競合の意味合いがネットワークアプリケーションという文脈を超えることを示す。 ## 強み / 弱点・課題 **強み** - ドメインごとのクレジットベースフロー制御という単一の抽象化で、既存研究の観測結果の説明と新規現象の発見の両方を統一的に扱える。 - Intel の uncore performance counters を用いたリバースエンジニアリングにより、非公開のハードウェア詳細(ドメインのクレジット数・レイテンシ)を実測から導出する手法を確立している。 - 解析式による定量的検証(全データ点で誤差10%以内、CHA admission delay加算後)により、相関ベースの説明にとどまらず因果的な理解を裏付けている。 **弱点・課題** - DDIO有効化がC2Mワークロード(単独実行時点でキャッシュミス率約100%)の劣化を悪化させる現象について、著者ら自身が説明を持ち合わせていないと明言している(§2.1)。 - 単一ソケット・単一IIO・2世代のIntelプロセッサに限定された検証であり、著者ら自身がマルチソケット・マルチIIO・AMDプロセッサ・CXL/NVLink等の新しいインターコネクトへの拡張を今後の課題として挙げている(§7)。 - 解析式はP2M-Read/RoCE/PFC/DCTCPのようなロッシー・輻輳制御を伴うシナリオの全詳細をモデル化しておらず、パケットドロップに起因する複雑な輻輳応答の組み込みは将来の拡張として残されている。