USENIX ATC '15 輪読会で発表したスライドです http://connpass.com/event/18210/

1. USENIX ATC 15
Memory Session
@aru132

2. 自己紹介
• @aru132
• 松宮 遼
• 電通大大山研M2
• 専門：HPCにおけるデータ管理手法とその応用
• キャッシュ、記憶装置階層、GPU、
(分散)ファイルシステム、メモリ、etc

3. Agenda
• Shoal: Smart Allocation and Replication of Memory For
Parallel Programs
• Thread and Memory Placement on NUMA Systems:
Asymmetry Matters (Best paper)
• Latency-Tolerant Software Distributed Shared Memory
(Best paper)
• NightWatch: Integrating Lightweight and Transparent
Cache Pollution Control into Dynamic Memory Allocation
Systems

4. Shoal: Smart Allocation and Replication
of Memory For Parallel Programs
• NUMA(マルチプロセッサ)環境を仮定
• こいつがなかなかスケールしてくれない

5. スケールしない原因
• mallocされたメモリ領域は、mallocが実行された
プロセッサと直接繋がっている場所に配置

6. 解決策
• mallocしたデータを各プロセッサにストライピング
• 空間局所性の高い処理に有効
• mallocしたデータを各プロセッサにレプリケーション
• 空間局所性の低い処理に有効
• どのような処理をさせるかによってどちらが適切かは
変わる

7. Shoal
• NUMA環境でメモリ管理を行
うための高レベルAPI
• libnumaとmadviseを使っ
て作成

8. Shoalを用いた実装
• DSLのコンパイラ等で使うことを想定
• 例ではGreen-Marl [ASPLOS 12]に実装
• グラフ処理のためのDSL

9. 性能

10. Thread and Memory Placement on
NUMA Systems: Asymmetry Matters
• Best paper 1本目
• プロセッサ間でのデータ通信を最適にするようにスレッド
を配置するスケジューラAsymSchedを作成
• プロセッサ間通信の(非対称な)トポロジーとバス速度に着目

11. スケジューリング方法
• 同じpidを持つスレッドをクラスタという単位で
グループ化
• クラスタ内で発生するデータ通信のバンド幅が最も
高速となるようにスケジューリング
• クラスタ間でのデータ通信は無視できるくらいに
少ないと仮定

12. スレッドのマイグレーション
• スケジューリングの結果によってはスレッドを元に
あったプロセッサ(上のメモリ)から他のプロセッサ
にマイグレーションする必要がある
• スレッドがメモリインテンシブな状態であれば、ス
レッドが使うメモリを全てマイグレーションする
• そうでないのならば、LinuxカーネルのDynamic
migrationを利用してマイグレーションする

13. 実験結果
• Bestな状態にかなり近づいた
• 提案しているスレッドのマイグレーション手法は、
Dynamic migrationのみを行った場合に比べ、
結果が発散しない

14. Latency-Tolerant Software
Distributed Shared Memory
• Best paper 2本目
• 1990年代に大流行していた分散共有メモリ(DSM)
の研究
• 2000年代は下火になっていたが、ここ数年で
復活の兆し
• ネットワーク技術の進歩(特にRDMA)が主な理由

15. Grappa
• C++11で実装されたDSMフレームワーク
• Infinibandで接続されたx86マシンクラスタを
仮定
• レイヤ的にはOSよりも上でMapReduceや
Hiveなどの下
• SparkやDryadやNaiadと同じレイヤ？

16. メモリレイアウト
実体はノード毎
内容は同一
異なるノードから
アクセス可能
異なるノードから
はアクセス不可能

17. Delegate
• 他のノードが持っているGlobal Heapへのアクセス
はDelegate operationを使って行う

18. メッセージのとりまとめ
• Grappaではノード間通信が頻繁に発生する
• そして通信するデータサイズは大きくないことが多い
→バンド幅が出ない
• メッセージをとりまとめて送受信することでバンド幅を向上させる

19. スレッドのプリフェッチ
• Grappaでは1コア辺り1000スレッド程度の処理を
行うことがある
• 1スレッド辺りのメモリ量は少ない
• コンテキストスイッチで発生するDRAMへの
アクセスがボトルネック
• スレッドの情報をプリフェッチするように
スケジューラを作成

20. パフォーマンス
• GraphLabと比較

21. NightWatch: Integrating Lightweight and
Transparent Cache Pollution Control into
Dynamic Memory Allocation Systems
• マルチコアCPUにおける共有CPUキャッシュ(L2 or L3)の話
• 共有CPUキャッシュは、いくつかの領域に分割されている
• それぞれの物理メモリページは、分割されたCPUキャッシュ
領域に(静的に)紐付けされている
• 紐付けされた領域にキャッシュされる

22. 問題点
• 共有CPUキャッシュのキャッシュヒット率が低いことが
ある
• ある仮想メモリ領域は時間的局所性の高いが、
別の領域は時間的局所性が低い場合

23. 解決策
• 時間的局所性の低い仮想メモリ領域に特化したCPU
キャッシュ領域を作ってしまう
• 具体的には、malloc時に割り当てる物理メモリページを
同じCPUキャッシュ領域となるように、うまく配置する

24. 解決策
• 時間的局所性の低い仮想メモリ領域に特化したCPU
キャッシュ領域を作ってしまう
• 具体的には、malloc時に割り当てる物理メモリページを
同じCPUキャッシュ領域となるように、うまく配置する
時間的局所性を
どうやって見分ける？

25. 時間的局所性の見分け方
• 2つの仮定をしている
• 近い仮想メモリ空間のメモリ領域は時間的局所性が似ている(はずだ)
• 同じコールスタック内でmallocされたメモリ領域は時間的局所性が
似ている(はずだ)
• サンプルに対して2回メモリを読み込み、その時間を測定
• 1回目と2回目がほぼ同じ→CPUにキャッシュされていた
• 1回目と2回目が全然違う→CPUにキャッシュされていなかった
• その結果で統計を取っていく

26. 実験結果