DIMM スロット装着型不揮発性メモリ上の RDMA によるメッセージ
キューイングシステムの試作
南里 豪志 1) , 大江 和一 2) , 吉田 英司 3) 、大辻 弘貴 3 、林 英里香 31) 九州大学 情報基盤研究開発センター
2) 国立情報学研究所
3) 株式会社富士通研究所
nanri.takeshi.995@m.kyushu-u.ac.jp

Preliminary Study of Message Queueing System based on RDMA
over Non-Volatile DIMM
Takeshi Nanri1) , Kazuichi Ooe2) , Eiji Yoshida3) , Hiroki Ohtsuji3) , Erika Hayashi3)
1) Research Institute for Information Technology, Kyushu Univ.
2) National Institute Informatics
3) Fujitsu Laboratories Ltd.

概要
近年、DRAM と SSD の間に位置づけられる新たな記憶装置として、DIMM スロットに装着する不揮発性メモリである Non-Volatile DIMM が注目されている。本研究では、代表的な NVDIMM である Intel Optane
Persistent Memory の読み書き速度が高速インターコネクト InﬁniBand の性能に近い点に着目し、この記憶装置
上に RDMA 通信を用いたメッセージキューイングシステムを試験的に構築して性能を評価した。これは、キュー
領域を DCPMM 上に配置するメッセージキューイングシステムであり、実装プロトコルとしては Push 型と Pull型の二通りを試した。このシステムにおけるメッセージ操作の性能を実機で計測したところ、キュー領域を DRAM上に配置した場合に対して遜色のない結果が得られたことから、DCPMM 上のメッセージキューイングシステムの実用性を確認した。また、DCPM にキューを配置した場合、メッセージサイズが大きくなるにつれて memcpy の
所要時間の影響が大きくなり、特にキューの出力側のプロセスでは、Push 型と Pull 型の優劣がメッセージサイズに応じて入れ替わることを確認した。一方、入力側のプロセスでは、Push 型の enqueue の時間が短いことから通信時間の隠ぺいが期待できることが分かった。

1 はじめにPMem は DRAM と組み合わせて利用することとなっており、DRAM を Last Level Cache として利用

計算の大規模化や、データサイエンスなどの計算機する Memory Mode、もしくは DRAM と PMem をア

利用の多様化に伴い、主記憶の容量に対する要求がプリケーション内で明示的に使い分ける App Direct

高まっている。そこで近年、容量単価が安価で集積度

Mode のいずれかの使用モードを選択して使用する。

の高い不揮発性メモリを DIMM スロットに装着する

Memory Mode では、アプリケーションを書き換えず

Non-Volatile DIMM (NVDIMM) 技術が注目されてに PMem の容量分の記憶空間を利用できるものの、局いる。例えば、この NVDIMM の代表的な製品の一所性が低いアプリケーションでは PMem への読み書つである Intel Optane Persistent Memory (PMem)

きが頻発するため、DRAM のみを使用する場合に対は、現時点で DRAM の 4 倍となる 512GB のメモリ

して性能が大幅に低下する。一方 App Direct Mode

モジュールが選択可能であり、今後さらに高集積化がでは、アプリケーションの変更が必要となるものの、見込まれていること、および読み書き遅延時間が数 µ

DRAM と PMem の容量を合わせた記憶空間を利用

秒と SSD の数十分の一であることから、DRAM とでき、さらに、データの読み書き頻度に応じてメモリ

SSD の間に位置づけられる新しい記憶階層として期待への配置を調整することにより、DRAM のみを使用

されている。

する場合に対する性能低下を抑制することが可能となる。

メモリとしてバイト単位で読み書きする方法が提供さ

このような PMem の特性を活用したアプリケーシれている。このうち従来のストレージと同様の方法でョンの例として、本研究では、Remote Direct Memory

は、通常のファイル I/O により読み書きが可能であAccess (RDMA) によるメッセージキューイングシス

るものの、PMem の性能を発揮させることはできな

テムの、PMem への実装を提案する。RDMA は、遠い。これに対してバイト単位で読み書きする方法とし隔の計算期間でメモリを読み書きする片方向の通信でては、さらに Filesystem DAX と、Direct DAX の二あり、非同期で効率的なデータ転送を可能とする。こ

通りから選択できる。Filesystem DAX は、PMem 上の RDMA を用いたメッセージキューイングシステムに構築したファイルシステムのファイルを mmap 関は、サーバクライアントモデルにおけるリクエスト機

数でマップすることにより、直接読み書きできるよう

構や、通信ライブラリにおけるメッセージ処理機構のにするものである。一方、Direct DAX は、I/O デバ

実装に用いられている [1]。通常、メッセージキュー

イスとして認識された PMem をプログラム中で直接イングシステムがメッセージの保管のために必要とな読み書きできるようにするものである。このうち本稿

るキュー領域は、データサイズや計算機の規模に比例では、最も高性能が期待できる Direct DAX を選択して増大する。そこで、このキュー領域を PMem にする。

配置することで、データや計算機の大規模化への対応

Linux における PMem の Direct DAX での利用方が可能となる。また、InﬁniBand のような高性能ネッ

法は、Intel 社の Web サイトに記述されている [6]。まトワークで計算ノード群を接続した並列計算機では、ず、PMem 管理ユーティリティ ipmctl を利用して、装この RDMA の遅延時間が 1µ 秒程度であり、PMem

着されている PMem を、region と呼ばれる領域としの遅延時間と同程度であるため、キュー領域としてて定義する。この時、個々の PMem メモリモジュール

DRAM の代わりに PMem を利用することによる性を別の region として定義する non-interleaved region

能への影響は小さいと期待できる。

と、複数の PMem メモリモジュールをまとめて一つPMem の基本性能に関する調査は盛んに行われての region として定義する interleaved region のいず

おり、いくつかが報告されている [2, 3, 4]。しかし、れかを選択できる。interleaved region では、複数のPMem 上にキュー領域を配置したメッセージキュー

メモリチャネルを使用することにより、読み書きの帯

イングシステムについての研究は、まだなされていな域幅が向上する。

い。本稿では、PMem 上に試験的にメッセージキュー

次に、Linux の NVDIMM 管理ユーティリティ nd-

イングシステムを構築し、DRAM 上に構築した場合

ctl コマンドを利用して、定義された region に names-との性能を比較して実用性を検証する。また、予備実

pace を登録する。これはファイルシステムにおけ験として実施した PMem の基本性能の計測結果も、るパーティションと同様の操作である。定義された

合わせて報告する。

namespace は、I/O デバイスとして Linux の /dev

2 PMem の概要
2.1 PMem を装着する DIMM スロットの選択

ディレクトリの中に現れる。
この I/O デバイスをプログラム中で open し、さらに mmap でメモリ領域としてマップすることにPMem は Intel 社 が 2019 年 に 販 売 を 開 始 し たより、直接読み書き可能となる。また、この領域をNVDIMM であり、DRAM と同様に DIMM スロッ

InﬁniBand の memory region として登録することにトに装着してバイト単位読み書きが可能である。ただより、RDMA による遠隔読み書きも可能である。なし、マザーボード上の DIMM スロットを PMem のみ

お、PMem 向けのプログラミングインタフェースとしで使用することはできず、必ず DRAM と組み合わせては、Intel 社が Persistent Memory Developing Kitて使用することが求められている。DRAM と PMem(PMDK) が提供されている [7]。これは、mmap 等を装着する DIMM の選択肢はマザーボードごとに決の操作を隠蔽して簡便に PMem を操作するものであめられており、それぞれのメモリモジュールの枚数や、る。これに対して本稿で計測に用いた各プログラム

使用モードに応じて選択する [5]。

は、PMem 本来の性能を評価するため、PMDK を介

2.2 Linux における PMem の設定

さずに作成した。

Linux では、PMem の利用方法として、従来のストレージと同様にブロック単位で読み書きする方法と、

3 RDMA によるメッセージキューイングシ
ステム
3.1

プログラミングインタフェース

ため、通信時間を隠蔽できない。
しかし、PMem では、RDMA write とローカルメ
モリへの書き込みが競合した場合の性能劣化の問題が報告されている [3]。そのため、PMem を用いたメッ

本稿で実装するメッセージキューイングシステム

セージキューイングシステムの実装では、Push 型とは、図 1 に示す通り、一対一の片方向キューで構成さPull 型の優劣は、この書き込み競合による性能劣化のれる。入力側プロセスが enqueue コマンドでキュー程度に依存する。そこで今回は、Push 型と Pull 型のに投入したメッセージを、出力側プロセスが dequeue

両方を実装し、性能を比較する。

コマンドで取り出すことで、メッセージの転送が完了

3.2.2

RDMA による実装

する。また、入力側プロセスは、ﬂush コマンドによPush 型、Pull 型、それぞれによる実装の概要を、り、投入したメッセージが取り出されたことを確認す

それぞれ図 2 および図 3 に示す。いずれの実装でも、ることができる。

入力側と出力側にそれぞれ二つのカウンタ変数を用意し、これらを更新することでキューを操作する。これ
らのカウンタは、実行開始時に 0 で初期化される。その後、入力側のプロセスが enqueue 命令を呼び出すと、キュー領域にメッセージをコピーし、自分の lctr s
カウンタを一つ増やして、その値を出力側のプロセス

図1

今回の実験で用いるメッセージキューイングシステムの rctr t に RDMA write する。一方、出力側のプロ
セスは、dequeue 命令の中で、自分の rctr t が lctr t

今回実装したシステムでは、キューは固定サイズのよりも大きくなるのを待って、キュー領域からメッエントリに分かれており、キュー内のエントリ数も固セージをコピーし、自分の lctr t を一つ増やして、そ定となっている。エントリの大きさを超えるメッセーの値を入力側のプロセスの rctr s にに RDMA write

ジを enqueue することはできない。また、enqueue 時する。入力側で、この rctr s が lctr s と一致するまでにキューが一杯になっている場合、出力側プロセスの待つのが ﬂush 命令である。これにより、メッセージ

dequeue により空きエントリが生じるまで待つ。一が出力側から取り出され、キューが空になったことを方、dequeue 時にキューが空である場合、入力側プロ確認できる。

セスの enqueue によりメッセージがキューに投入されるまで待つ。

3.2 PMem 上への実装
3.2.1 実装の方針
今回の実装では、データ転送だけでなく、カウンタなどの管理情報の操作もすべて RDMA で実装する。

図 2 Push 型によるキューイングシステムの実装

これにより入力側は、キューが空いていれば、出力側のプロセスの状況によらずに enqueue 操作を完了することができる。RDMA を用いたメッセージキューイ
ングシステムの一般的な実装として、キュー領域を出力側のプロセスのメモリ領域に配置する Push 型と、入力側のプロセスのメモリ領域に配置する Pull 型があげられる。
多くのメッセージキューイングシステムでは Push

図 3 Pull 型によるキューイングシステムの実装型が選択されている。これは、Push 型が enqueue 時にデータを出力側のメモリに RDMA write するため、

dequeue 側で並行して計算を進めることで、通信時間

これらの実装で用いるカウンタは、全て DRAM 上の隠ぺいが期待できるためである。一方 Pull 型は、に配置している。これは、カウンタの操作が RDMA

dequeue 時に入力側のメモリから RDMA read するだけでなくプロセス内でも頻繁に発生することから、

表1

PMem に配置すると遅延時間が問題となると考えられ実験に使用した計算機たためである。また、RDMA 通信の対象とするため、これらのカウンタを並べた配列は posix memalign 関
数により 8 バイト境界で確保し、ibv reg mr 関数を用いて登録している。

CPU
DRAM
Pmem

Push 型ではキュー領域を出力側のプロセスのメ
モ リ 上 に 配 置 し 、入 力 側 の enqueue 命 令 発 行 時 にRDMA write によってメッセージを書き込む。一方、Motherboad
OS
Network

出力側が dequeue 命令を発行すると、キュー領域上Intel Xeon Silver 4215 (2.50GHz) x 1
DDR4 2400MT/s, 8GB x 4 slots
Intel
OptanePersistent
Memory,2400MT/s, 128GB x 2 slots
Supermicro X11SPL-F
Cent OS 8.1 (kernel 4.18.0)
InﬁniBand
Connect-IB,
MLNX OFED LINUX-4.7-3.2.9.0のメッセージを memcpy 関数で目的の場所にコピーする。
表 2 DRAM と PMem の配置

これに対して Pull 型では、キュー領域を入力側のプ
ロセスのメモリ上に配置し、入力側の enqueue 命令発
行時に memcpy 関数でメッセージをキュー領域にコ

配置名

PMem1

PMem2

ピーする。出力側は、dequeue 命令発行時に RDMA

スロット A1

DRAM

read によってメッセージを直接目的の場所にコピー

スロット A2

空きスロット B1
スロット D1

DRAM
PMem
DRAM

DRAM
PMem
DRAM

が RDMA の対象になるため、これらの領域もあらかスロット D2

空き

じめ ibv reg mr 関数を用いて NIC に登録しておき、スロット E1

さらに、アドレスと rkey をプロセス間で交換しておスロット F1

DRAM
PMem

する。
このように、メッセージの転送元、もしくは転送先スロット C1

空き

DRAM
PMem
DRAM
空き

く。今回は実験用のシステムであったため、これらの準備はプログラムの初期化処理で済ませているが、実際のプログラムでは、プログラマがメモリ上の任意の使用した計算機の仕様を表 1 に示す。この計算機 2 台

場所を登録するためのインタフェースを用意する必要

を InﬁniBand スイッチで接続し、性能を計測した。

がある。

な お 、こ の 計 算 機 の マ ザ ー ボ ー ド で 使 用 可 能 な

このシステムについて、キュー領域を PMem に

DIMM スロット数は 8 である。そこで、DRAM と配置した場合と DRAM に配置した場合の性能を比PMem の配置として、表 2 に示す PMem1 と PMem2

較する。DRAM 上にキュー領域を配置する場合は、の二通りを試した。このうち PMem1 は、Intel 社推

posix memalign を用いて 8 バイト境界で領域を確保

奨の構成であり、CPU が持つ 6 本のメモリチャネルする。一方、PMem に配置する場合、PMem を Directにそれぞれメモリモジュールを 1 個ずつ割り当てる

DAX で利用する。そのため、I/O デバイスをプログラ

ため、読み書き時のメモリチャネルの競合は発生しな

ム中で open し、さらに mmap でメモリ空間にマップい。これに対して PMem2 は、同じメモリチャネルにしたものをキュー領域として使用する。なお、PMem

DRAM と PMem を混在させることによる性能へのを同時に複数の用途で使用する場合、Direct DAX で影響を調査するための構成で、非推奨である。

は PMem 内の領域確保や空き領域管理をユーザレベ

4.2

ルで行う必要がある。しかし今回の実験では PMem

4.2.1の全領域をキュー領域として占有するため、特別なメ
モリ管理等は行っていない。

4 実験結果4.1

実験環境

基本性能調査ローカル読み書き性能

ローカル読み書き性能として、まず、計算機内のメモリへの読み書きにおける遅延時間を計測した。計測に使用したプログラムは、コピー先とコピー元の位置をそれぞれ指定したストライドで移動しながら 1 バイトのデータコピーを繰り返すものである。コピー元と本節では、PMem と DRAM を混載したシステムにコピー先のメモリ領域を DRAM、PMem1、PMem2

おける、基本性能およびメッセージキューイングシス

から選択し、ストライドを変化させながら遅延時間をテムの性能計測に関する実験結果を報告する。実験に計測した結果を図 4 に示す。横軸がストライド、縦軸

が遅延時間である。
0.0001

PMem2 to PMem2
PMem1 to PMem1
DRAM to PMem2
DRAM to PMem1
PMem2 to DRAM
PMem1 to DRAM
DRAM to DRAM

40000

Bandwidth (MB/sec)

1×10-5

1×10-6Time (sec)

PMem2 to PMem2
PMem1 to PMem1
DRAM to PMem2
DRAM to PMem1
PMem2 to DRAM
PMem1 to DRAM
DRAM to DRAM

50000

30000

20000

1×10-7
10000

1×10-8

0

1

2

4

8

Number of Threads
1×10-9
4

16

64

256

1K

4K

16K

64K

図5

256K

ローカル読み書き帯域幅

Stride (Byte)

図 4 ローカル読み書き遅延時間低下することも分かった。
コピー元とコピー先としていずれのメモリ領域を選一方、コピー先が PMem の場合は、メモリ配置が択した場合でも、ストライドが小さい間は遅延時間がPMem1、PMem2 のいずれを選択しても帯域幅が約短くなっているのはキャッシュの効果によるものであ

1GB/秒であり、スレッド数を増やしても変化しない

る。また、いずれの場合も、8KB 以上のストライド

ことが分かった。これにより、PMem の書き込み帯域

では遅延時間がほとんど変化しなくなるため、この範幅が 1GB/秒程度であることが確認できた。

囲での計測値が、キャッシュの効果を含まない遅延時

4.2.2

RDMA 性能間であると考えられる。DRAM から DRAM へのコ

DRAM および PMem に対する RDMA の性能を、

ピーでは、この遅延時間が 20〜30n 秒であるのに対OFED に付属していた Performance Tests のコマン

し、PMem1 から DRAM へのコピーが約 70n 秒でドにより計測した。使用したコマンドは、ib read lat

あった。また、コピー先が PMem1 の場合は、コピー（RDMA Read 遅延）、ib read bw（RDMA Read 帯域

元が DRAM、PMem1 のいずれの場合も、遅延時間幅）、ib write lat（RDMA Write 遅延）、ib write bw

が約 180n 秒であった。これにより、特に PMem へ（RDMA Write 帯域幅）である。これらは全て、サーの書き込みに要する時間が大きいことが確認できた。

バクライアント型となっており、サーバ側の計算機

また、PMem2 から DRAM へのコピーが約 180nに対してクライアント側が RDMA 命令を発行する。

秒、DRAM もしくは PMem2 から PMem2 へのコ

サーバ側、およびクライアント側について、それぞれピーが約 800n 秒と、PMem1 の場合に比べてさらに

メモリ領域として DRAM、PMem1、PMem2 を選択

大幅な性能低下が見られた。PMem1 と PMem2 の性した場合の、各コマンドの計測結果を図 6、7、8、9 に能差についての原因は調査中である。

示す。

次に、計算機内のメモリへの読み書きの帯域幅を計

メ ッ セ ー ジ サ イ ズ が 128 バ イ ト 以 下 の 場 合 の測した。計測に使用したプログラムは、STREAM ベ

RDMA Read 遅延 時 間 は 、サ ー バ 側 のメ モ リ 領 域

ンチマーク [8] の COPY コードである。遅延時間計測

が DRAM である場合、すなわち遠隔の DRAM かと同様、コピー元とコピー先のメモリ領域を DRAM、ら読み出す場合には、クライアント側のメモリ領域

PMem1、PMem2 から選択し、1GB のデータのコピー

が DRAM、PMem1、PMem2 のいずれの場合も約における帯域幅を、スレッド数を変化させながら計測

1.9µ 秒程度であった。一方、サーバ側のメモリ領域がした。計測結果を図 5 に示す。

PMem1 もしくは PMem2 の場合、遅延時間が約 2.2µ

計 測 結 果 か ら 、コ ピ ー 先 が DRAM の 場 合 の 、

秒と、若干長くなった。

PMem1 や PMem2 からのコピーの帯域幅は、DRAM

また、RDMA Read 帯域幅も、16KB 以下の転送サからのコピーの帯域幅の約半分、もしくはそれ以上とイズでは、PMem1 もしくは PMem2 から読み出す場なることが確認できた。また、遅延時間ほどではない

合に性能低下が見られた。これはローカル読み書きのものの、PMem1 に対して PMem2 で読み出し性能が性能と逆の傾向であり、原因を調査中である。一方、

PMem2 to PMem1
PMem1 to PMem2
DRAM to PMem2
DRAM to PMem1
PMem2 to DRAM
PMem1 to DRAM
DRAM to DRAM

Time (micro sec)

10

Time (micro sec)

10

1

4

16

64

256

1K

PMem2 to PMem1
PMem1 to PMem2
DRAM to PMem2
DRAM to PMem1
PMem2 to DRAM
PMem1 to DRAM
DRAM to DRAM

1

0.1

4K

4

16

64

Size (Byte)256

図 6 RDMA Read 遅延時間

Bandwidth (MB/sec)

6000

PMem2 to PMem1
PMem1 to PMem2
DRAM to PMem2
DRAM to PMem1
PMem2 to DRAM
PMem1 to DRAM
DRAM to DRAM

8000

Bandwidth (MB/sec)

PMem2 to PMem1
PMem1 to PMem2
DRAM to PMem2
DRAM to PMem1
PMem2 to DRAM
PMem1 to DRAM
DRAM to DRAM

8000

4K

図 8 RDMA Write 遅延時間

10000

10000

1K

Size (Byte)

6000

4000

4000
2000

2000
0

256

2K

16K

128K

1M

8M

Size (Byte)
0

256

2K

16K

128K

1M

8M

図 9 RDMA Write 帯域幅

Size (Byte)

図 7 RDMA Read 帯域幅

4.3メッセージキューイングシステムの性能

4.3.1

性能計測の概要

RDMA によるメッセージキューイングシステムの8MB の転送時の帯域幅は、PMem1 もしくは PMem2

性能を計測する。計測では、2 台の計算機にそれぞれに書き込む場合に低下している。これはローカル読み

キューの入力側プロセスと出力側プロセスを起動し、書きと同様の傾向であるものの、8MB より小さい転

その間でメッセージを転送する。前述の通り、Push

送サイズではいずれの場合も高い帯域幅が計測される型の場合は出力側、Pull 型の場合は入力側のプロセ

原因は、今のところ不明である。

スにキュー領域を確保する。さらに、Push 型、Pull

次に、RDMA Write 遅延時間は、いずれのメモリ

型、それぞれキュー領域を確保するメモリ領域として領域の組み合わせでもほとんど同じであった。なお、

DRAM、PMem1、PMem2 を選択した場合の性能を全体的に RDMA Write が RDMA Read より低遅延比較する。いずれの場合も、キュー領域として 10GBとなるのは、Read ではクライアントからサーバに送を配置し、これを 32MB のスロットに分割して使用付した読み出し要求に応じてデータ転送が開始されする。

るのに対して、Write ではクライアントが直接サーバ計測に用いたプログラムでは、入力側プロセスがにデータ転送を開始するためである。一方、RDMA

メッセージの enqueue と ﬂush を繰り返し、出力側プ

Write 帯域幅の傾向は、RDMA Read 帯域幅とほぼ同ロセスは、計算と dequeue を繰り返す。出力側プロセ様であった。

スの計算としては行列積を用い、各メッセージサイズ

での通信時間と計算時間の比率が大きく変動しないよ同様、全体の所要時間は、メッセージサイズが小さい

うに、行列サイズをほぼメッセージサイズの三乗根に場合に Pull 型よりも Push 型が短く、メッセージサ

比例して増加させる。今回の実験では繰り返し回数をイズが大きくなるにつれてその優劣がほとんど見られ

100 回とし、それぞれの操作の所要時間の平均値を計なくなる。また、この傾向は Dequeue に要した時間

測結果として示す。

にも現れている。これは、Push 型の場合、Dequeue

4.3.2 入力側プロセスの所要時間の中で入力側プロセスによるキュー領域への RDMA

図 10 に、入力側のプロセスの Enqueue と Flush にWrite とカウンタへの RDMA Write の完了を待つ時

要した時間を示す。Enqueue と Flush の合計時間を間、およびキュー領域からアプリケーション領域へ

見ると、メッセージサイズが小さい場合、Pull 型よりのメモリコピーに要する時間が必要であり、特にメッPush 型が高速である。これは、Push 型では入力側のセージサイズが大きい場合にメモリコピーの時間がEnqueue でデータ転送が開始されるため、出力側の計

無視できなくなるためである。さらに、今回用いたプ

算とデータ転送が並行して進むことにより通信時間を

ログラムは 1 スレッドで動作するため、図 5 で見た隠蔽できたことによるものと考えられる。また、Push

通り、DRAM から DRAM へのコピーであっても帯型で Enqueue 時間がメッセージサイズによらず一定

域幅が 13GB/秒程度であり、図 7 で示した RDMAになっているのは、Enqueue 内の RDMA Write 命令

Read の帯域幅 6GB/秒に対して大きな優位性が無い

が、データ転送の完了を待たずに終了するためである。

ことも、メモリコピーに要する時間による影響が大き

一方、メッセージサイズが大きくなると Push 型とい要因として考えられる。なお、出力側プロセスでもPull 型の優劣がほとんど見られなくなる。特にキューPMem1 と PMem2 の間での性能の差異はほとんど見領域として PMem1 もしくは PMem2 を使用した場られなかった。

合、32MB で Push 型と Pull 型の優劣が逆転する。こ1.0000000

れは、Push 型では出力側の dequeue 時にキュー領域
0.1000000

からアプリケーション領域へのメモリコピーが必要であり、この時間がメッセージサイズの増加に伴って無0.0100000

め、メモリコピーに要する時間の影響が顕著に出たと考えられる。なお、PMem1 と PMem2 の間での性能の差異はほとんど見られなかった。
1.0000000

0.1000000

Time (sec)0.0100000

0.0010000

Time (sec)

視できなくなることが原因である。特に PMem1 やPMem2 は読み出しの帯域幅が DRAM よりも狭いた

0.0010000

Push DRAM to DRAM other
Push DRAM to DRAM dequeue
Push DRAM to PMem1 other
Push DRAM to PMem1 dequeue
Push DRAM to PMem2 other
Push DRAM to PMem2 dequeue
Pull DRAM to DRAM other
Pull DRAM to DRAM dequeue
Pull PMem1 to DRAM other
Pull PMem1 to DRAM dequeue
Pull PMem2 to DRAM other
Pull PMem2 to DRAM dequeue

0.0001000

0.0000100

0.0000010

Push DRAM to DRAM flush
Push DRAM to DRAM enqueue
Push DRAM to PMem1 flush
Push DRAM to PMem1 enqueue
Push DRAM to PMem2 flush
Push DRAM to PMem2 enqueue
Pull DRAM to DRAM flush
Pull DRAM to DRAM enqueue
Pull PMem1 to DRAM flush
Pull PMem1 to DRAM enqueue
Pull PMem2 to DRAM flush
Pull PMem2 to DRAM enqueue

0.0000001

1K

8K

64K

512K

4M

32M

Message Size (Byte)

図 11

出力側プロセスの所要時間

一方、[3] では、RDMA Write とローカルメモリへの0.0001000

書き込みが競合した場合に、ローカルメモリの書き込み性能が低下する現象が報告されている。本稿のメッ

0.0000100

セージキューイングシステムでは、Push 型でキュー領

0.0000010

域を PMem1 もしくは PMem2 に確保した場合に、入0.0000001

1K

8K

64K

512K

4M

32M

Message Size (Byte)

図 10 入力側プロセスの所要時間

力側プロセスからキュー領域への RDMA Write と出力側プロセスの計算で競合が発生すると考えられる。
そこで、各方式での出力側プロセスの計算時間を図 12に示す。図からわかる通り、Push 型、Pull 型、どち4.3.3 出力側プロセスの所要時間

らも、DRAM と PMem1、PMem2 での有意な性能

図 11 に、出力側のプロセスの Dequeue と、それ差は見られない。すなわち、今回の実験では、RDMA以外の処理に要した時間を示す。こちらも、入力側とWrite とローカルメモリへの書き込みの競合による性能低下は確認できなかった。
1.0000000

0.1000000

10.1145/2619239.2626299[2] Hirofuchi, T. et al, ”A Prompt Report on the

Push DRAM to DRAM comp
Push DRAM to PMem1 comp
Push DRAM to PMem2 comp
Pull DRAM to DRAM comp
Pull PMem1 to DRAM comp
Pull PMem2 to DRAM comp

Performance of Intel Optane DC PersistentMemory Module”, IEICE Trans. Inf. and Syst.,
vol. E103-D, no. 5, pp. 1168-1172, 2020. DOI:

0.0100000
Time (sec)

10.1587/transinf.2019EDL8141[3] Oe, K., ”Analysis of Interference between

0.0010000

RDMA and Local Access on Hybrid Memory
0.0001000

System”, Aug. 2020. arXiv:2008.12501v1[4] Weiland, M. et al, ”An early evaluation of

0.0000100

Intel’s optane DC persistent memory module
0.0000010

1K

8K

64K

512K

4M

32M

and its impact on high-performance scientiﬁc

Message Size (Byte)

applications”, SC’19: Proceedings of the In図 12 出力側プロセスの計算時間

ternational Conference for High Performance
Computing, Networking, Storage and Analysis,
Nov. 2019. DOI: 10.1145/3295500.3356159

5 むすび
SSD より高速で DRAM より大容量化が期待でき[5] Module DIMM Population for Intel Optane
Persistent Memory. https://www.intel.com/

る新しい記憶装置 NVDIMM の代表的な製品である

content/www/us/en/support/articles/

PMem について、まず基本性能を計測した。その結

000032932/memory-and-storage/data-

果、ローカルの読み書き性能は DRAM より大幅に劣center-persistent-memory.html

るものの、RDMA 通信の性能に近いことを確認した。

[6] Quick Start Guide:DC

Provision Inte Op-

これにより、RDMA 通信を利用したアプリケーショ

tanePersistent

Memoryンでは、DRAM を PMem に置き換えることによる性//software.intel.com/content/www/us/

能低下が抑制できると期待できる。そこで、RDMA

en/develop/articles/quick-start-guide-

通信を用いたメッセージキューイングシステムにおいconfigure-intel-optane-dc-persistent-て、キュー領域を PMem に確保した場合と DRAM にmemory-on-linux.html

https:

確保した場合の性能を比較した結果、全体として性能[7] Programming Persistent Memory https://

差が小さく、十分実用性が期待できることが分かった。

software.intel.com/content/www/us/en/

また、メッセージキューイングシステムの実装手段

develop/topics/persistent-memory.html

としては、メッセージサイズが小さい場合は、通信隠蔽効果により Push 型が Pull 型に対して有利であった。しかしメッセージサイズが大きい場合、出力側プロセスの Dequeue におけるメモリコピーに要する時間が影響し、Pull 型に対する優位性が見られなくな
り、特に PMem にキューを配置する実装では、 Push型と Pull 型の優劣が入れ替わることが分かった。なお、既存研究で報告されていた、PMem への RDMA

write とローカルメモリへの書き込みの競合による性
能劣化については、今回の実験では確認できなかった。

参考文献[1] Kalia, A. et al, ”Using RDMA eﬃciently
for key-value services”, Proceedings of SIGCOMM’14, pp. 295-306, Aug. 2014. DOI:

[8] STREAM

Benchmark

http://www.cs.

virginia.edu/stream/ref.html