日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

GPU コードから分散ファイルシステムにアクセスする
試み
松宮 遼

髙橋 一志

大山 恵弘

我々は分散ファイルシステム上のファイルを GPU コードで読み書きする API を開発している．この API を開発する上で，いくつかの課題が浮上している．GPU コードから CPU コードの呼び出す方法が通常の GPU プログ
ラミング環境には存在しないこと，PCI Express のバス速度が低速であること，クライアント内で余分なメモリコ
ピーが発生することである．本稿は，それらの課題に対して我々が取った対策について論じるものである．

We are developing an API to operate files on a distributed file system from GPU code. Several issues arefound during this development; the limitation of bus speed of PCI Express, no method to call CPU codefrom GPU code in standard GPU software development kits, and extra data copies in the client. This paper
describes our solutions to these issues.

ファイルの読み書きを行うためのクライアント API

1 はじめにを独自に提供している．しかしそれらのクライアント

TSUBAME-KFC [5] のように，Graphic Process-API では，GPU で実行されるコード (GPU コード)ing Unit (GPU) を積極的に利用したクラスタマシン

からファイルの読み書きを直接行うことができない．

がある．そのようなマシンは，気象シミュレーショ

GPU 上でファイルの読み書きを行おうとした場合，ン [20] から深層学習 [4] に至るまで幅広く利用され計算機はファイルの内容を一度マザーボード上のメており，それらの分野で扱われる問題規模は日々増大

インメモリ (ホストメモリ) 上に転送し，その後，メしている．事実，Microsoft では 10〜100 TB もの入インメモリ上のデータを GPU 上の VRAM (デバイ

力データを用いた深層学習を行っている [3]．

スメモリ) に転送することが一般的である．このデー

巨 大 な デ ー タ を 扱 う 場 合 ，フ ァ イ ル は ext4 やタ転送処理はソースコードを複雑にする．その上でbtrfs [17] といったローカルファイルシステムではプログラムの最適化を行うことにより，ソースコード

なく，Gfarm [24] や HDFS [21]，GlusterFS [16]，はより複雑となる．

PVFS [2] といった分散ファイルシステムで管理す

そこで我々は GPU コード上で分散ファイルシステることが一般的である．分散ファイルシステムの一

ム上のファイルを読み書きする機構を API として提部は，CPU で実行されるコード (CPU コード) から供することを提案し，実装を行っている．提案機構の実装を行う上で，いくつかの課題が浮かび上がった．

Attempting to access a distributed file system fromGPU code.
This is an unrefereed paper. Copyrights belong to
the Author(s).
Ryo Matsumiya, 電 気 通 信 大 学, The University ofElectro-Communications.
Kazushi Takahashi and Yoshihiro Oyama, 電気通信大
学 / 科学技術振興機構 CREST, The University ofElectro-Communications / CREST, Japan Scienceand Technology Agency.

本稿では，これらの課題を取り上げた上で，我々が取ろうとしている解決策について述べる．本稿で取り上げる課題と解決策とは，以下の 3 つである．

• 近年の GPU は PCI Express (PCIe) によって接続されていることが多い．PCIe のバス速度は，

GPU コアからデバイスメモリに対するバス速度に比べて十分に低速である．我々はデバイスメ

GPU Cores

317 GB/s
Device Memory

CPU Cores

PCIe
16 GB/sGPU

図1

48 GB/s
Host Memory
Host

デバイスメモリとホストメモリの関係，
値は本稿で述べる実験環境の理論値．

モリ上にファイルの内容をキャッシュさせるよ
うにした．

• 一般的な GPU プログラミング環境は，CPUコードから GPU コードを呼び出す機構のみが備わっており，GPU コードから CPU コードを呼__kernel plus_kernel ( a [] , b [] , c []){c = a + b;}
plus ( a [] , b [] , c []){d_a = gpuMalloc ( sizeof ( a ));d_b = gpuMalloc ( sizeof ( b ));d_c = gpuMalloc ( sizeof ( c ));memcpyHtoD ( d_a , a , sizeof ( a ));memcpyHtoD ( d_b , b , sizeof ( b ));kernelLaunch ( plus_kernel , d_a , d_b ,d_c );
memcpyDtoH (c , d_c , sizeof ( c ));gpuFree ( d_a );gpuFree ( d_b );gpuFree ( d_c );}び出す機構は，現状備わっていない．しかしながら，分散ファイルシステムサーバへの接続を行う
時は CPU コードが実行される必要がある．した

図2

GPU による一般的な行列加算プログラムの擬似コードがって，我々は GPU コードから CPU コードを呼び出す Remote Procedure Call (RPC) 機構のリにアクセスする場合や，GPU コアがホストメモリ実装を行った．

にアクセスする場合は，PCIe のバスを経由する必要• GPU が読み書きを行うデータについては，通がある．このアクセス速度は，CPU コアがホストメ

常，ホストメモリとデバイスメモリの間でメモリモリにアクセスする速度や，GPU コアがデバイスメ

コピーが発生する．我々は，ファイルの読み込み

モリにアクセスする速度に比べて十分に遅い．従っを行う際，GPUDirect RDMA [11] を用いるこて，GPU を用いたプログラムでは，デバイスメモリとでホストメモリとデバイスメモリのコピーをのみを使って処理を行うことが一般的である．

削減した．メモリコピーの削減により，ファイルの読み込み速度が向上することを確認した．

2. 2 GPU のプログラミングモデル

本稿の構成を述べる．2 章では背景となる GPU に

CUDA [9] や OpenCL [14] といった一般的な GPU

ついて説明する．3 章では我々が開発している API

プログラミング環境でのプログラミングモデルにの設計と実装について，4 章では我々が開発しているついて述べる．GPU を用いた一般的な行列加算プ

API の現在の性能に関する実験について述べる．5 章

ログラムの例を擬似コードとして図 2 に示す．関数では我々が開発している API の移植性や，実験で得

plus kernel() は 2 つの行列 a, b を受け取り，その和られた知見についての議論を行う．6 章で関連研究にを行列 c に書き込むものである．関数 plus kernel()

ついて説明し，7 章でまとめと今後の課題について述は GPU 上で処理される．GPU 上で処理される関数

べる．

はカーネル関数とよばれる．関数 plus() は，関数

plus kernel() を GPU 上で実行するための処理を2 GPU行う関数で，CPU 上で実行される．関数 plus() で

2. 1 GPU のメモリ階層

はまず，関数 gpuMalloc() を用いて，GPU の処理に

図 1 で示した通り，最近の GPU は PCIe によって必要なメモリ領域をデバイスメモリ上に確保する．確

接続されている．つまり，CPU コアがデバイスメモ

保されたメモリ領域には関数 memcpyHtoD() によっ

NIC

NIC
DeviceHost

MemoryMemoryHostMemoryGPU

図3

DeviceMemoryGPU(左)GPUDirect RDMA を利用していない場合のデータのフロー(右)GPUDirect RDMA を利用した場合のデータのフローて，ホストメモリ上にある入力データがコピーされる．

では，GPUDirect RDMA に対応した NVIDIA 社製

カーネル関数の呼び出しは，通常の関数の呼び出しとの GPU とネットワーク環境が必要となる．また，は異なる．例では関数 kernelLaunch() を用いて関GPUDirect RDMA を用いて一度に転送できるデー

数 plus kernel() を呼び出している．カーネル関数

タサイズには限度がある [10]．そのため，GPUDirectの実行結果はデバイスメモリ上に保存され，カーネル

RDMA を用いたプログラムの開発者はそのデータサ

関数の実行が終わった後にホストメモリに転送されイズを考慮しなければならない．

る．例では，関数 memcpyDtoH() を用いて，カーネル関数によって書き込まれた行列の和を，ホストメモリ

3 設計と実装

上にコピーしている．コンパイラは，関数に与えられ

3. 1 API の仕様ているアノテーションをもとに CPU コードか GPU

本研究では，分散ファイルシステムの Gfarm に対コードのどちらにコンパイルするかを決定する．例でして我々のチームが開発している RDMA 実装 [18]は， kernel アノテーションを関数 plus kernel()を対象とし，GPU コード上で Gfarm 上のファイルに与えることで，GPU コードとしてコンパイルするを読み書きする API を実装した．API を実行するマようにコンパイラに指示している．GPU コードから

シンは，NVIDIA 社製の，GPUDirect RDMA に対CPU コードの関数を呼び出す機構は現在のところ標応した GPU を搭載したもので，NVIDIA 社公式の

準では実装されていない．

GPU プログラミング環境である CUDA によってプログラムが開発されていると仮定する．

2. 3 GPUDirect RDMA

CUDA では多くの場合 C あるいは C++でソース

ネットワーク上のデータをデバイスメモリに転送

コードを記述する．そこで我々が提供する API は Cする，あるいはデバイスメモリ上のデータをネット

言語によるものである．Gfarm では POSIX-like のワーク上のノードに転送する場合，図 3 の左で示す

API を libgfarm として公式に提供している．我々のように，ホストメモリを一度経由する必要がある．

API も POSIX-like のものとした．現在までに実装

GPUDirect RDMA と呼ばれる NVIDIA 製の一部のが完了しており，API で提供している関数の一覧を

GPU に実装されている機能を用いることで，図 3 の

表 1 および表 2 に示す．表 1 は CPU コード上で呼右で示すようにホストメモリを経由することなく，び出される関数であり，表 2 は GPU コード上で呼びデバイスメモリの内容をネットワーク上のノードか出される関数である．

ら読み書きすることができる．GPUDirect RDMA

開発中の API を用いて，行列加算プログラムのカー

表1

CPU コードで実行する API 関数の一覧

関数名

説明

ginitialize

API の内部処理に必要なメモリ領域の確保と Gfarm サーバへの接続を行う．

ghandleカーネル関数の実行を開始した後に呼び出す．
この関数が呼び出される前に実行を開始したカーネル関数が全て終了するまで待機する．

gfinalize

ginitialize で確保したメモリ領域の解放と Gfarm サーバとの接続の切断を行う．

表2

GPU コードで実行する API 関数の一覧

関数名

説明

gopen

与えられた URL に対応する Gfarm 上のファイルを開き，ファイルの識別子を返す．

gwrite

与えられたファイルオフセットに対してファイルの書き込みを行う．

gread

与えられたファイルオフセットに対するファイルの読み込みを行う．

gclose

与えられた識別子に対応するファイルを閉じる．

gfstat

与えられた識別子に対応するファイルのサイズを返す．

__kernel plus_kernel ( a [] , b [] , c []){int fd_a , fd_b , fd_c ;gopen (" File_a " , O_RDONLY , & fd_a );gopen (" File_b " , O_RDONLY , & fd_b );gopen (" File_c " , O_WRONLY , & fd_c );gread ( fd_a , a , 0 , gfstat ( fd_a ));gread ( fd_b , b , 0 , gfstat ( fd_b ));c = a + b;
gwrite ( fd_c , c , 0 , gfstat ( fd_c ));gclose ( fd_a );gclose ( fd_b );gclose ( fd_c );}図4

3. 2 キャッシュの実装
2. 1 節で述べたように，最近の GPU は PCIe で接続されている．GPU コアからホストメモリへのバス
速度は，GPU コアからデバイスメモリへのバス速度に比べて遅い．
そこで我々はデバイスメモリ上にファイルの内容をキャッシュさせるようにした．我々が実装したキャッシュ機構は Linux カーネルで利用されているページ
キャッシュと同様に，固定長のものである．キャッシュ戦略は，実装が容易である先入れ先だし (FIFO)
戦略を取った．

開発中の API を用いた行列加算プログラムのカーネル関数擬似コード

3. 3 RPC 機構の実装
ネットワーク機器の制御を行うには，OS が提供しネル関数を記述すると図 4 のようになる．このカーているシステムコールを使う必要がある．つまり，提ネル関数では，まず，File a，File b，File c とい案機構の実現のためには GPU コードから CPU コー

うファイル名のファイルを関数 gopen() で開く．入ドを呼び出す RPC 機構を実装する必要がある．しか力値の記述されたファイル File a，File b の内容をしながら，2. 2 節で述べたように，GPU コードから

関数 gread() でファイルの先頭 (オフセットが 0) かCPU コードの関数を呼び出す RPC 機構は標準では

らファイルサイズ分だけ読み込む．ファイルサイズ

実装されていない．

は関数 gfstat() にて取得する．その後行列の加算

そこで我々は GPU コードから CPU コードの関数処理を行い，結果を関数 gwrite() を用いてファイルを呼び出す RPC 機構を実装した．この RPC 機構はFile c に書き込む．最後に 3 ファイル全てを閉じる．

GPUfs [22, 23] や GPUnet [8] で用いられているものと同様のものである．

を転送する．データの転送が終わると，それをクライ

GPU

アントの CPU に通知する．クライアントの CPU は

Yes

Cached?

Complete

通知を受け取ると，GPU に処理を返す．GPU は転送されたデータを読み込み，処理を完了する．

No
Enough memory?

3. 4 GPUDirect RDMA の利用
我々が開発している API では，ファイルの内容を転No送するのに，2. 3 節にて説明した GPUDirect RDMA
Yes

Evict old cachesを利用する．しかし，GPUDirect RDMA を用いてデバイスメモリ上のデータを他ノードに送信するとEnqueue request

Wait response

バンド幅が非常に小さい場合があることが，いくつかの既存研究により示されている [12, 15]．そこで我々はファイルシステム上のファイルの内容を読みDequeue request

込む時にのみ GPUDirect RDMA を利用するようにした．キャッシュの書き戻しを行うとき，CPU は

Read from server

Return to GPUCPU

図5

関数 gread() の処理の概略図

GPUDirect RDMA を利用せず，一度ホストメモリ
上にキャッシュの内容をコピーしてからサーバにアップロードする．

4 実験
我々の API で発生するオーバーヘッドと，GPUDi-

RPC 機構はキューにより構成されている．キュー

rect RDMA の効果を検証するために実験を行った．

は 1 つのプロセスにつき 1 つずつ，ホストメモリ上に存在する．GPU が API に対してどのような命令

4. 1 実験環境を行ったかという情報をキューに追加する．CPU は

実験は，クライアント 1 台と分散ファイルシステ

キューに命令が追加されたことを確認すると，その命

ムサーバ 1 台から構成された InfiniBand FDR 4X

令に応じた処理を行い，結果を GPU に返す．GPUによるネットワーク上で行われた．クライアントのは CPU から結果が返ってくるまで処理をブロック

CPU は Intel Core i7-4770K，メモリサイズは 32 GB，する．

GPU は NVIDIA Quadro M6000，OS は CentOS 7，

図 5 は関数 gread() の処理の概略である．まず，InfiniBand の NIC は Mellanox ConnectX-3 である．

キャッシュがデバイスメモリ上に存在するかを確認す

サーバの CPU は Intel Xeon E5-2665，メモリサイズ

る．もしキャッシュされていれば，キャッシュから読は 32 GB，OS は CentOS 7，InfiniBand の NIC はみ込む．キャッシュされていなかった場合は，キャッMellanox ConnectX-3 であり，HDD は SAS 6 Gbps

シュ領域の空き容量を確認する．キャッシュ領域の空

で 15000 rpm のものを使用した．

き容量が，読み込みを行うサイズよりも小さかった場

本稿において No API は，我々の開発している API

合はキャッシュの掃き出しを行う．キャッシュ領域のを利用せず，RDMA 版 Gfarm のクライアント API

空き容量が十分ならば，キューに読み込みのリクエスを用いて実装した場合を表す．Without GDR は我々

トを追加し，CPU からの応答を待つ．CPU はキューの開発している API で GPUDirect RDMA を利用しからリクエストを取り出し，サーバにリクエストを送なかった場合，Proposal が GPUDirect RDMA を利信する．サーバはデバイスメモリにファイルの内容用した場合をそれぞれ表す．

%#"%#!!!!!"%#"%!!!"%!!!!!!"%!!!!!!"%!"%!"%!!!!!!"
%!"
%!"

$#!!"
$#!!!!!"$#!!!!!"
$#"
$#"
$!!!"
$!!!!!!"*+",-."&'"()*"/012+31"456"+,-.'/-"012"$!!!!!!"$!"#!!"#!!!!!"-7+8+9:;")3'4'567"$!"#!!!!!"
#" !"

!"

#"

!" !"

図6

$#!!!!!"$#"$#"*+",-."&'"()*"/012+31"456"+,-.'/-"012"$!!!!!!"$!"-7+8+9:;")3'4'567"$!"#!!!!!"#"$" $" %" %" &" &" '" '" $("$(" )%")%" (&"(&" $%'"$%'" %#("%#(" #$%"-./'(%.0'(+12,!
./0'(%/1'(+23-!
$"

%"

&"

&'"()*"*+",-."!"!"#$%&'()&*#)+,-!
!"#$%&'"()*'(+,%-!
!"#$%&'()&*#)+,-!

!"#$%&'()&*#)+,-!
!"#$%&'"()*'(+,%-!
!"#$%&'()&*#)+,-!
!"#$%&'"()*'(+*%,!
!"#$%&'"()*'(+,%-!

%#"%#!!!!!"%#"%#!!"%#!!!!!"

'"

$("

)%"

(&"

./0'(%/1'(+23-!
+,-.'/-"012"/012+31"456"$%'" %#(" #$%"

)3'4'567"-7+8+9:;"シーケンシャルリードにおけるデータ転送時間

#"

!" !"
!"

図7

$"

%"

&"

&'"()*"

'"

$("

)%"

(&"

./0'(%/1'(+23-!
+,-.'/-"012"$%'" %#(" #$%"

)3'4'567"

文字列マッチングプログラムの実行時間

No API と Without GDR におけるデバイスメモ

トファイルをもとに，検索対象ファイルを読み込む．

リでのキャッシュ領域の大きさを 2 GB とした．しか辞書ファイルに記載されている全ての単語について，

し，2. 3 節にて説明したように，GPUDirect RDMA

検索対象ファイルに含まれている数を出力するもので使用できるデバイスメモリ領域の大きさには制限である．1 単語につき 1 スレッド割り当てられ，各スがあるため，Proposal についてはキャッシュ領域のレッドは割り当てられている単語が検索対象ファイ大きさを 64 MB とした．また実験はサーバのページ

ル上に存在する数をカウントする．
本実験で用いた辞書 †1 は 58000 単語，ファイルサ

キャッシュをクリアした上で行っている．

4. 2 シーケンシャルリード

イズにして 1.8 MB 掲載されており，Shakespere の作品集 †2 5.2 MB 分のテキストファイルを検索対象

Gfarm 上のファイルに対してシーケンシャルリーとした．検索対象リストファイルのサイズは 16 B でドを行い，サーバ上のディスクからデバイスメモリ

ある．

に，Gfarm 上のファイルの内容が転送されるまでの結果を図 7 に示す．出力ファイルの大きさは 5.5 MB

総時間を図 6 に示す．GPUDirect RDMA を利用しとなった．我々の開発している API では，GPUDirect

なかった場合，我々の開発している API を利用しな

RDMA の利用を問わず，API を利用する前に比べてかった場合に比べて転送時間は最悪 1.3 倍となる．し0.97 倍の実行速度を得ることができた．

かしながら，GPUDirect RDMA を利用した場合の転送時間は，我々の開発している API を利用しなかっ5 議論た場合と比較して，最悪でも 1.01 倍，最高では 0.69

我々の開発している API を利用せず，libgfarm な

倍となる．

どの CPU コード向けの API のみを利用する場合，

GPUDirect RDMA を利用することは不可能である．
4. 3 文字列マッチング

その結果，クライアントの内部で最低でも 1 回のメモ

我々の開発している API を利用した場合と，利用リコピーが発生する．4. 2 節では，我々の開発していしなかった場合で文字列マッチングを行うプログラ

る API により，Gfarm 上のファイルの内容を転送す

ムをそれぞれ作成し，実行時間を測定した．これは検る時間が短縮されることがあるということを示して索する単語が記載されている辞書ファイルと，検索いる．また，アプリケーション全体を通しても，我々対象とするファイル名が列挙されている検索対象リ†1 http://www.mieliestronk.com/wordlist.html†2 http://www.gutenberg.org/ebooks/100

ストファイルをまず読み込む．そして検索対象リス

の開発している API がアプリケーションの実行時間

イルシステムのクライアントで利用した初の試みでに対して影響が小さい場合があることを 4. 3 節ではある．

示している．
近年のクラスタマシンは，GPU ではなく，Xeon

7 まとめと今後の課題

Phi [6] を搭載する場合がある．Xeon Phi も，GPU

我々は分散ファイルシステムの Gfarm を対象とし，と同様にデバイスメモリを内蔵しており，GPUDirect

GPU コードでファイルの読み書きを行う API を開RDMA と同等のデータ転送機構を持っている．した発している．現在まで，GPU コードから CPU コー

がって，本稿で論じた手法は，Xeon Phi に移植する

ドを呼び出す RPC 機構およびデバイスメモリ上でのことが可能である．

キャッシュ機構の実装を行った．また，GPUDirect

提案システムでは，GPUDirect RDMA に対応しRDMA を利用することで，ファイル読み込み時にた環境を想定している．しかしながら，GPUDirect

サーバと GPU 間で発生する通信時間を削減するこ

RDMA に対応していない環境でも，クライアントとに成功し，GPUDirect RDMA が分散ファイルシ

内のメモリコピーを削減する手法が提案されていステムのクライアントでは有効に機能することを示る [1]．この手法は Gdev [7] などの NVIDIA 非公式

した．

の GPU デバイスドライバを利用する必要があるため

現在の API ではファイルの作成や削除といった，

本研究では取り入れていない．この手法を用いるこ

ファイルシステムの操作で必須となる一部の処理がとで，GPUDirect RDMA に対応していない環境で未実装である．これらの機能の実装をまず完了させも，GPUDirect RDMA を導入したときと同様の効る必要がある．またキャッシュに関しても改善の余果が得られると考えられる．

地は多い．FIFO 戦略ではなく，広く利用されている

Least-Recently-Used 戦略の導入を検討することや，

6 関連研究デバイスメモリだけでなく，ホストメモリも用いた

本研究と特に密接に関連した研究として GPUfs

キャッシュ機構の導入が考えられる．これらの実装[22, 23] が挙げられる．GPUfs はローカルファイルシを行った上で，より詳細な評価実験を行うことを予定

ステムを対象とし，GPU コードからファイルの読みしている．

書きを行えるようにしたものである．本研究の対象

謝辞 本研究を行うにあたって，筑波大学の建部修見

は分散ファイルシステムである．また，GPUfs の研教授及び HPCS 研究室ビッグデータグループの方々

究では，本稿で行ったクライアント内でのメモリコより有益な助言を頂いた．また本研究は科学技術振興

ピーについての議論を行っていない．

機構 CREST の研究課題「ポストペタスケールデー

GPUDirect RDMA を導入したシステムソフト
ウェアがいくつか発表されている．Oden ら [13] は，タインテンシブサイエンスのためのシステムソフト
ウェア」の支援を受けている．

InfiniBand の Verbs API を GPU コードから呼び出すためのライブラリを開発した．Potluri ら [15]，参 考 文 献Venkatesh ら [25]，Shi ら [19] は，GPU が搭載され[ 1 ] Anh, N. V., Fujii, Y., Iida, Y., Azumi, T.,
Nishio, N., and Kato, S.: Reducing Data Copies between GPUs and NICs, the Proceedings of the IEEE
International Conference on Cyber-Physical Systems, Networks, and Applications (CPSNA ’14),
2014.
[ 2 ] Carns, P. H., LigonIII, W. B., Ross, R. B., andThakur, R.: PVFS: A Parallel File System for Linux
Clusters, the Proceedings of the 4th Annual LinuxShowcase and Conference (ALS ’00), 2000.
[ 3 ] Chilimbi, T., Suzue, Y., Apacible, J., and Kalya-

たマシンのクラスタを仮定し，GPUDirect を用いる
ことで，MPI で行われるノード間通信の高速化を試みている．GPUnet [8] は，UNIX におけるソケット
通信を GPU で実現させるためのライブラリである．

GPUnet では，GPUDirect RDMA が有効な環境では GPUDirect RDMA を利用して通信を行うようにしている．本研究は，GPUDirect RDMA を分散ファnaraman, K.: Project Adam: Building an Eﬃcient and Scalable Deep Learning Training System,
the Proceedings of the 11th USENIX Symposium
on Operating Systems Design and Implementation(OSDI ’14), 2014.
[ 4 ] Coates, A., Huval, B., Wang, T., Wu, D.,
Catanzaro, B., and Andrew, N.: Deep learningwith COTS HPC systems, the Proceedings of the
30th International Conference on Machine Learning (ICML ’13), 2013.
[ 5 ] Endo, T., Nukuda, A., and Matsuoka, S.:
TSUBAME-KFC: A Modern Liquid Submersion
Cooling Prototype towards Exascale Becoming theGreenest Supercomputer in the World, the Proceedings of the 20th IEEE International Conference on
Parallel and Distributed Systems (ICPADS ’14),
2014.
[ 6 ] Intel: Xeon PhiTM Product Family, http://
www.intel.com/content/www/us/en/processors/xeon/
xeon-phi-detail.html.
[ 7 ] Kato, S., McThrow, M., Maltzahn, C., andBrandt, S.: Gdev: First-Class GPU Resource Management in the Operating System, the Proceedings of the USENIX Annual Technical Conference(USENIX ATC ’12), 2012.
[ 8 ] Kim, S., Huh, S., Hu, Y., Zhang, X., Witchel, E.,
Wated, A., and Silberstein, M.: GPUnet: Networking Abstractions for GPU Programs, the Proceedings of the 11th USENIX Symposium on Operating
Systems Design and Implementation (OSDI ’14),
2014.
[ 9 ] NVIDIA Corporation: CUDA Zone, http://developer.nvidia.com/cuda-zone.
[10] NVIDIA Corporation: Developing a Linux Kernel Module using GPUDirect RDMA, http://docs.
nvidia.com/cuda/gpudirect-rdma/.
[11] NVIDIA Corporation: NVIDIA GPUDirect,
http://developer.nvidia.com/gpudirect.
[12] NVIDIA Corporation:
NVIDIA/gdrcopy GitHub, https://github.com/NVIDIA/gdrcopy.
[13] Oden, L., Froning, H., and Pfreundt, F.-J.:
Infiniband-Verbs on GPU: A Case Study of Contorolling an Infiniband Network Device from theGPU, the Proceedings of the 4th International
Workshop on Accelerators and Hybrid Exascale
Systems (AsHES ’14), 2014.
[14] OpenCL - Khronos Group: Khronos Group,https://www.khronos.org/opencl/.
[15] Potluri, S., Hamidouche, K., Venkatesh, A., Bureddy, D., and Panda, D. K.: Eﬃcient Inter-node
MPI Communication using GPUDirect RDMA for
InfiniBand Clusters with NVIDIA GPUs, the Pro-

ceedings of the 42nd International Conference on
Parallel Processing (ICPP ’13), 2013.
[16] RedHat, Inc.: Write once, read everywhere Gluster, http://www.gluster.org/.
[17] Rodeh, O., Bacik, J., and Mason, C.: BTRFS:
The Linux B-Tree Filesystem, ACM Transactions
on Storage (TOS), Vol. 9, No. 9, 2013.
[18] Sasaki, S., Takahashi, K., Oyama, Y., andTatebe, O.: RDMA-based Direct Transfer of File
Data to Remote Page Cache, the Proceedings ofthe 2015 IEEE International Conference on Cluster
Computing (CLUSTER ’15), 2015.
[19] Shi, R., Potluri, S., Hamidouche, K., Perkins,J., Li, M., Rossetti, D., , and Panda, D. K.: Designing Eﬃcient Small Message Transfer Mechanism
for Inter-node MPI Communication on InfiniBand
GPU Clusters, the Proceedings of the 21st International Conference on High Performance Computing(HiPC ’14), 2014.
[20] Shimokawabe, T., Aoki, T., Muroi, C., Ishida,J., Kawano, K., Endo, T., Nukuda, A., Maruyama,N., and Matsuoka, S.: An 80-Fold Speedup, 15.0
TFlops Full GPU Acceleration of Non-Hydrostatic
Weather Model ASUCA Production Code, the Processing of the 2010 International Conference forHigh Performance Computing, Networking, Storage and Analysis (SC ’10), 2010.
[21] Shvachko, K., Kuang, H., Radia, S., andChansler, R.: The Hadoop Distributed File System, the Proceedings of the IEEE 26th Symposiumon Mass Storage Systems and Technologies (MSST’10), 2010.
[22] Silberstein, M., Ford, B., Keidar, I., andWitchel, E.: GPUfs: Integrating a File System with
GPUs, the Proceedings of the 18th International
Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’13), 2013.
[23] Silberstein, M., Ford, B., Keidar, I., andWitchel, E.: GPUfs: Integrating a File System with
GPUs, ACM Transactions on Computer Systems(TOCS), Vol. 32, No. 1, 2014.
[24] Tatebe, O., Hiraga, K., and Soda, N.: Gfarm
Grid File System, New Generation Computing,Vol. 28, No. 3, Ohmsha, Ltd. and Springer, 2010.
[25] Venkatesh, A., Subramoni, H., Hamidouche, K.,
and Panda, D. K.: A High Performance Broadcast Design with Hardware Multicast and GPUDirect RDMA for Streaming Applications on Infiniband Clusters, the Proceedings of the 21st International Conference on High Performance Computing(HiPC ’14), 2014.