PM / RHiNET の特徴と問題点

PM/RHiNETではメッセージの転送にPUSH^{を用いているため，}Martini^{のハードウェアによる}

通信処理を活かすことができ，高い基本通信性能を発揮することが期待される．

しかし，一方で，すべてのノードが送信ノードごとに十分な大きさの受信領域を確保しなけれ ばならないため，通信ノード数の増加に比例して受信バッファとして必要なメモリが増加してし まうという問題がある^(注3)．また，受信データが到着していない場合，1度のpmReceiveの呼び 出しですべての受信領域の受信状況を確認して回ることになるため，ノード数が増大した場合に 受信のオーバヘッドが大きくなってしまうことが予想される．この問題を検証するために，実機 を用いた測定を行った．

(注3)この点に関してはSEND/RECV^{も同様である．}

評価環境

評価は，64^{ノード構成の}RHiNET-2^クラスタ(^図8.3)^のうち，16^{台のノード}PC^{を，完全結合}

した4^台のRHiNET-2/SW^{に対してそれぞれ}4台ずつ接続することで構築したクラスタ上で行っ

た．評価に用いたノードPC^の構成は7.5^{節において表}7.2で示したものと同様である．

また，PMについては，SCoreバージョン5.8.2に付属のものを元に実装を行った．PM/RHiNET の各ノードに対応する個々の受信バッファのサイズは128Kbyteとし，すべてページ境界にアライ ンした配置とした．スループットおよびレイテンシの評価では，SCoreに付属のテストプログラ ムであるpmtestを用いた．

図8.3 RHiNET-2^クラスタ

ノード数のレイテンシに対する影響の評価

まず，ノード数が増えた場合に，メッセージの到着検出に要するオーバヘッドが受信レイテン シにどの程度影響するかを評価するため，全体のノード数を2^，4^，8^，16^{と変化させた際の}2^ノー ド間のピンポン転送時のRTTを測定した．ピンポン転送のRTT^は，2ノードが互いに相手からの メッセージを受信後，直ちに返送する処理を繰り返すことで測定している．結果を図8.4^に示す．

全体のノード数が8までは，RTTは2ノードの場合と比べてほとんど変化がないが，16ノード 時に約1.8µsecが大きくなっている．この差は，受信バッファの確認処理の際の，ホストCPUの L2^{キャッシュや}TLBにおけるミスヒットによるオーバヘッドに起因すると考えられる．

10 20 30 40 50 60 70 80 90 100

1 4 16 64 256 1k 4k 16k

Round Trip Time (µsec)

Size (byte) 2 nodes

4 nodes 8 nodes 16 nodes

図8.4 PM/RHiNETにおけるノード数増加のRTT^への影響

先に述べたように，PM/RHiNET^では，PUSHの書き込み先の領域は必ず2Kbyte^{単位にアライ} ンしたアドレスとなる．そのため，メッセージ到着のためにポーリングする領域は2Kbyteにアラ インされたアドレスとなり，キャッシュ上でのポーリング対象領域のラインが衝突する確率はラン ダムなアドレスをポーリングした場合と比べて大幅に高くなる．また，受信バッファの確認の際 に広範囲にアクセスを行うことでTLBが汚染されてしまうため，メッセージ受信後のアプリケー ションの実行性能にも影響するものと考えられる．

そこで，メッセージ到着確認によるメモリアクセスが性能に与える影響を確認するために，同 一のホストPC上で，受信バッファに見立てたバッファを複数用意し，各々に対して順番にアクセ スしてすべてに対するアクセスが完了するまでに要する時間の測定を行った．結果を図8.5に示す．

各受信バッファのサイズは，評価で用いたPM/RHiNET^と同様に128Kbyte^{とし，ページ境界に} アラインするよう配置した．測定では，メッセージ到着検出処理として，バッファ上の2Kbyte^に アラインしたアドレスから4byteのデータの読み出しを行った．図中の“Head”^{は，特定のノード} との間でのみメッセージ通信が行われている状況を想定して，各受信バッファの先頭アドレスを アクセス対象として順番にアクセスして回った際の所要時間を示している．一方，“Random”は，

各ノードからある程度メッセージが到着し，受信バッファが適度に埋まった状況を想定して，個々 の受信バッファ上の2Kbyte単位にアラインされたアドレスからランダムに選択した一つを順番 にアクセスして回った際の所要時間を示している．Head^{ではバッファ数}64^以上で，Random^で はバッファ数128以上で，それぞれバッファ確認に要する時間が大幅に増大していることがわか

る．Randomの場合，アクセス対象はページ先頭か，ページ先頭+2Kbyte^{となるのに対し，}Head

ではアクセス対象はページ先頭のみとなるため，HeadはRandomに比べてアクセス対象のキャッ

0.01 0.1 1 10 100

2 4 8 16 32 64 128 256 512 1024

Time (µsec)

Number of Buffers Head

Random

図8.5 メッセージ到着検出時のバッファアクセスの所要時間

シュラインの衝突確率が2^{倍となる．バッファ数}64で両者の値に差が生じているのはこのためで ある．バッファ数が128^{以上になると，}Random^とHeadの間でキャッシュラインの衝突の頻度に 大きな差がなくなることからほぼ同一のアクセス時間を示すようになっており，128^{ノードの場} 合少なくとも9µsec程度，それ以上ではノード数の増加に比例して受信処理のオーバヘッドが増 大している．この結果より，PM/RHiNETを用いた場合，ノード数の増大に伴いメッセージ到着 確認時間がRTTの数倍に達し，上位通信ライブラリを組み合わせた通信処理の性能に大きく影響 を及ぼすことが予想される．

なお，図8.5に示した結果では，バッファ数が16^{の場合，図}8.4で示した結果と異なり，メッ セージ到着検出に伴うオーバヘッドはほとんど発生していない．これは，図8.5^{の測定ではメモリ} アクセスのみを連続して行っているため，メッセージ到着検出後に別の処理を行うPM/RHiNET を用いたベンチマークに比べ，キャッシュやTLBのミスヒットが発生しにくいことによると考え られる．

ノード数のスループットに対する影響の評価

次に，全体のノード数を2，4，8，16と変化させた際の2ノード間のバースト転送におけるス ループットの測定を行った．スループットは，送信側のノードが受信側ノードに対して連続して メッセージを送信し，受信側のノードは受信のみを行うことで測定をしている．結果を図8.6^に 示す．

スループットは，転送サイズが小さいうちは，2^{ノードの場合も}16ノードの場合もほとんど差

0 50 100 150 200

1 4 16 64 256 1k 4k 16k

Throughput (Mbyte/s)

Size (byte) 2-node

4-node 8-node 16-node

図8.6 PM/RHiNETにおけるノード数増加のスループットへの影響

がないが，転送サイズが1Kbyte^{以上では，}16ノードの場合のみわずかに低くなっている．

メッセージサイズが小さい場合，メッセージ受信関数が呼ばれてメッセージを受信してから再 度メッセージ受信関数が呼ばれるまでの間に次のメッセージが到着するため，無駄な受信バッファ の参照がほとんど生じずノード数の影響が出にくい．これに対し，メッセージサイズが1Kbyte^以 上の場合，ホスト上で受信バッファの先頭にPMのメッセージのヘッダが新たに書かれたことを 確認した直後に，メッセージのトレイラが格納される領域をアクセスしても，受信データのホス トメモリへのDMA転送が完了していないため，データ末尾の検出ができないという状況が発生 する．その際，PM/RHiNETは一旦受信をあきらめ，他のノードからのメッセージ到着確認を行 うが，図8.4に示したように，16ノードの場合，8ノードの場合に比べて受信バッファ全体を確認 して回るのに時間を要する．これがスループットの低下につながっているものと考えられる．