TLB によるアドレス変換

2.2.1節で述べたように，RHiNETのネットワークインタフェースにはアドレス変換機構が必要

となる．そこで，Martini^{に対して，内部に}Physical Address Translation Look-aside Buffer (PATLB) と呼ばれるTLBを設け，ユーザから指定された仮想アドレスを高速に物理アドレスに変換可能な 機能を設けた．

また，PATLBのエントリがミスヒットした際のリプレースメント処理は，Martini^{の基本方針に}

従いハードウェア実装せず，ホスト上のデバイスドライバやMartiniのオンチッププロセッサ上で 動作するファームウェアで行えるような設計とした．

4.2.4 ローカルホストとリモートホストにおけるメモリ保護

ユーザレベル通信では，通信バッファはユーザプロセスによって指定されるため，OS^のプロ トコルスタックを用いたアドレスの検証を行うことができない．そのため，ネットワークインタ フェースはOSに代わってメモリ保護機構を提供しなければならない．そこで，Martiniのメモリ アクセスを以下のポリシーで制限するものとし，設計を行った．

• プリミティブを発行したプロセスのピンダウンされたメモリ領域へのアクセスを許可

• プリミティブを発行したプロセスと同じ並列ジョブに参加しているリモートプロセスのピン ダウンされたメモリ領域へのアクセスを許可

• それ以外のメモリ領域に対するアクセスはすべて禁止

Martini^{では，プロセス}IDの管理方法が異なる可能性のあるOS間での通信に対応し，また同

一並列ジョブ内のプロセスを確実に識別するために，OSによって提供されるプロセスID^の代わ りに次の2つの値を導入し，これらを用いてメモリ保護を実現する．

• Process Group ID (PGID)

各並列ジョブを識別するためのユニークなID

• Process ID (PID)

同一の並列ジョブに属している並列プロセスを識別するためのユニークなID

図4.2は，ネットワークインタフェースにMartiniを用いたクラスタシステムにおけるプロセ ス実行の流れの一例である．ユーザが並列ジョブの実行をシステムに対して要求すると，マスタ タスクマネージャ(並列処理システム全体を管理するプロセス)が並列ジョブに対してユニークな PGIDを割当て，並列プロセスの実行要求とそのプロセスに割当てるPIDを，PGIDとともに各 ノード上のタスクマネージャ(スレーブタスクマネージャ)^{に対して送る}(1)^{．各ノード上のスレー} ブタスクマネージャは，未使用のいくつかのWindow^{をプロセス用に予約し}(2)^，Process Group ID Table (PGIDTBL)^{と呼ばれる}Window^とPID^およびPGIDの対応を管理するテーブルの，予約し たWindow^{に対応するエントリに}PGID^とPID^{を書き込む}(3)^．PGIDTBL^に適切なPGID^とPID を書き込んだ後，スレーブタスクマネージャは並列プロセスを実行し(4)，プロセスは予約されて

いるWindowを自身のメモリ領域にマップする(5)．プロセスがWindowを介して通信要求を発行

すると，Martini^はWindow^のID^を元にPGIDTBL^{を参照して}PGID^とPID^{を取得する．}

このようにPGIDTBLのエントリをスレーブタスクマネージャなどの特権プロセスのみが設定 できるように制限し，ハードウェアが通信時にこれを直接参照することで，PID^やPGID^の詐称 を防止する．

PATLBを参照する際のキーとして，仮想アドレスにPGID^とPIDを以下のように組み合わせて

用いると，Martiniのポリシーに沿ったメモリ保護が実現することになる．

• ローカルのメモリ領域にアクセスする場合，プリミティブを発行したプロセスのPGIDと PIDを用いてローカルのPATLBを参照する

• リモートのメモリ領域にアクセスする場合，プリミティブを発行したプロセスのPGID^とリ モートプロセスのPID^{でリモートの}PATLB^{を参照する}

図4.2 RHiNETを用いたシステムにおけるプロセス実行の一例

ただし，この場合，PATLBに不正な物理アドレスが登録されていないことを何らかの形で保証 する必要がある．

4.2.5 リモートアドレスの抽象化

PUSH^やPULLは，メッセージ通信と異なり，リモートライト・リードの対象となるリモートの 領域を送信側で指定する通信モデルである．そのため，プリミティブを発行するプロセスは，通 信に先立ち他のプロセスの変数や配列などのデータが配置されている領域のアドレスを知る必要 がある．

しかしながら，リモートのデータが配置されている領域の仮想アドレスは，同一のプログラム を実行した場合でも動的に確保した場合などにプロセス間で異なる値となる可能性があるため，

リモートのデータを指し示すのに仮想アドレスを使用する場合，ユーザプログラムは各データの アドレスを他の並列プロセスとの間で事前に教えあう必要が生じる．これはプログラムを複雑化 し，また，実行開始時に多くの通信を必要とする．

そこで，これを回避するために，リモートの通信領域を指すための識別子として，OS^によって 提供される仮想アドレスの代わりにSegment ID (SID)と呼ばれる識別子を導入することにした．

SIDはポインタ配列に対するインデックスのような存在であり，各SIDはプロセス領域の通信バッ ファとしてPUSHの書き込み先やPULLの読み出し元として用いるデータ領域の先頭を指す．SID とそれに対応する仮想アドレスをプロセス実行時に通信処理に先立ってMartini^{上に登録してお}

き，Martini^がpush^{パケットや}pull要求パケットを受信した際に，パケットのヘッダに書かれた対

象プロセスのSIDを仮想アドレスに変換し，それをさらにPATLBを介して物理アドレスに変換す ることで，SIDを用いたリモートの仮想アドレスの抽象化が可能となる．さらにパケットヘッダ にオフセット値を持たせ，SIDから仮想アドレスを得た後，これにオフセット値を加えた上で物

理アドレスを得るようにすることで，配列などのデータ構造を扱いやすくすることができる．SID を用いることで，プログラマはリモートの領域をプログラミングの段階で指定可能となり，プロ セス間での仮想アドレスの交換が不要となる．

このようなSIDから仮想アドレスへの変換は，pushパケットやpull要求パケットを受信するた びに発生するので，これを高速に行うためにMartini^内部にSID–^{仮想アドレス変換用の}TLB^であ るRemove Virtual Address TLB (RVATLB)^{を設けることとした．}

ローカルホストでPUSH要求が発行されてからパケットが送出されるまでのアドレス変換を含 む処理の流れの例を図4.3^{に示す．図}4.3^{の例では，}4Kbyte^{単位にアラインされた}Window^のうち，

ユーザのアドレス空間にはIDが1のものがマップされている．ユーザがWindowに，通信要求に 必要となる各種パラメータを書き込み，キックを行うと，Martini内部でWindowの内容の処理が 開始する．Martini^は，まずWindow^のID^を元にPGIDTBL^{を参照し，}Window^{を利用しているプ} ロセスのPGID^とPIDを取り出す．次に，この値と，ユーザから指定のあった送信データの領域 の仮想ページ番号をキーとしてPATLBを参照し，対応する物理ページ番号を得る．これに，ユー ザ指定の仮想アドレスのページ内オフセットを加え，通信データの置かれた領域の物理アドレス

を得る．MartiniはDMAを用いて，この物理アドレスの領域からデータを読み出し，別途作成し

ておいたパケットヘッダと接合してpushパケットとしてネットワークへ送出する．

図4.3 ローカル側でのアドレス変換

一方，リモートノードにおいて，pushパケットを受信してから，データがリモートメモリに書 き込まれるまでのアドレス変換の流れの例を図4.4に示す．Martiniは，まず受信したpushパケッ トのヘッダに書かれている宛先プロセスのPID^，PGIDおよび書き込み先領域が含まれるセグメン トのSID^{をキーとして}RVATLB^{を参照する．}RVATLB^からは，SIDに対応した宛先ユーザプロセ スのセグメントの開始仮想アドレスが得られる．これに，同じくパケットヘッダに書かれたSID からのオフセット値を加え，書き込み先領域の仮想アドレスを生成する．この仮想アドレスのペー

ジ番号と，先ほど利用した宛先プロセスのPID^とPGID^{をキーとして，今度は}PATLB^{を参照し，}

書き込み先の物理ページ番号を取得する．この物理ページ番号に，仮想アドレスのページ内オフ セットを加えることで，書き込み先の物理アドレスを取得する．取得した物理アドレスの領域に，

MartiniはDMAでデータを書き込む．

図4.4 リモート側でのアドレス変換