次世代コンピューターシステムの妄想と不揮発性メモリを活用したファイルシステム

情報科学若手の会 2016 冬の陣

Transcript

1. 次世代コンピューターシステムの妄想と 不揮発性メモリを活用したファイルシステム @MakotoShimazu 2016/01/23 情報科学若手の会 冬の陣 2016
2. 自己紹介 島津 真人 (しまづ まこと) ▪ 東大　情報理工 M2 （修論まっただなか） ▪ HW / SW ▪ 研究ではLinuxのファイルシステムを作成中 (おとといやっと動いた！！ ٩( ’ω’ )و） ▪ 趣味ではEYEoT作ったり(mononome1), ロボットつくったり (PILE2) ▪ ロボコンくらすた (NHK大学ロボコン2010-2013) ▪ chromiumのこみったー 1: http://monono.me 2: http://pileproject.com 2
3. wakate2016wに向けて 今日の発表登録した動機 ▪ 修論発表 (練習が2/1…orz) に向けてスライドをつくらないといけない！ ▪ ケツをたたく必要がある！ ▪ お、若手の会よくね？ｗ ▪ かねてから大学外で発表してみたいとおもってたし！ ▪ とうろくしちゃえーー( ◠‿◠ ) 話すこと ▪ 修論でやったこと, ファイルシステムやOSについて話します ▪ ただ、今のテーマになるまでに 「”次世代のコンピュータ”は今となにが違うのか？？」 ということを結構調べたので、それを重点的にお話したいとおもいます！ 3
4. コンピューターの進化 速く, もっと速く！ 4
5. ところで速くするってなにを？ CPU ▪ 計算するやつ。命令を実行するやつ。 ▪ イメージ：速くなれば計算が速くなるからやっぱ速くなりそうじゃん? ストレージ（二次記憶装置、HDD、SSD） ▪ 永続化されたデータをとっておく場所 ▪ イメージ：SSDだと起動が速いよねーー ネットワーク（Ethernet, 光ファイバ) ▪ コンピューター同士の通信をするやつ ▪ イメージ：さいきんギガフレッツとか言って1Gbpsの回線やってるけど速いんだ ろうか… メモリ（主記憶装置、DRAM） ▪ CPUの計算をとっておくやつ ▪ イメージ：メモリが速くなるといいことあるの？！ 5
6. 以前のコンピューターの進化 かつての高速化 ▪ ちっさくつくれば？ →たくさんトランジスタを詰められる！ ▪ さらには →電圧が下がる！ ▪ 電圧が下がれば？ →遅延が小さくなる！ ▪ さらには →消費電力が下がる！ ▪ つまり、 小さくつくれば →高速で低消費電力で複雑なCPUができる！ ▪ といういい時代だった　（デナードスケーリング） ▪ コストもどんどん下がっていくという時代　（ムーアの法則） 他のデバイス ▪ メモリは微細化でドンドン増える！ ▪ ディスクは容量が増えていった一方で遅いまま。 (HDD -> SSD) 6
7. 現在のコンピューターの進化 CPU ▪ メニーコア, GPGPU ▪ 右脳型(非ノイマン型）アーキテクチャ メモリ ▪ 縦に積むことでの容量の増加 ▪ CPUと物理的に近くなることでの広帯域化 ストレージ ▪ NAND Flashから次世代不揮発性メモリへ ネットワーク ▪ 光をつかってクラスタを構築 ▪ チップ内まで直接光をもってきたり ▪ (ネットワークは詳しくないので , 今回は割愛します///) 7 詳しくは年末にblog記事書いたので見てもらえたら喜びます: http://goo.gl/pOfoOx
8. CPUの高速化: Meny Core Many Core ▪ Xeon Phi: 60C/240T, x86 Compatible, 1.0GHz, 1TFlops ▪ PEZY-SC: 1024C, 733MHz, 1.5TFlops ▪ TILE-Gx: 72C, 1.2GHz left) http://www.intel.co.jp/content/www/jp/ja/processors/xeon/xeon-phi-detail.html center) http://www.pezy.co.jp/news/PEZY_PR_20140905.pdf right) http://www.tilera.com/products/processors/TILE-Gx_Family 8
9. CPUの高速化: 対エネルギー エネルギーあたりの計算の高速化 ▪ GREEN 500 (1Wでどれだけ計算できるかランキング） GREEN500: http://www.green500.org/lists/green201511&green500from=1&green500to=100 9
10. CPUの高速化: 特定用途の高速化 ノイマン型アーキテクチャ ▪ メモリにプログラムをおいて、それを読み取ったり書き込んだりして計算するも の。 ▪ 非ノイマン型はそれ以外のもの たとえば ▪ アナログコンピューター (積分する回路は積分の計算を高速にできる！） ▪ 右脳型コンピューター (IBM SyNAPSEなど) ▪ FPGA (金融のHigh Frequency Trading) 10 http://www.ibm.com/smarterplanet/jp/ja/brainpower/
11. Memory Improvements Bandwidth ▪ HBM (High Bandwidth Memory) up to 256GB/s (DDR3: 12.8GB/s, GDDR5 88GB/s) ▪ TCI 91Tbps!!!1 Capacity ▪ 2.5D/3D Stacking 1) http://news.mynavi.jp/series/moore/003/ fig) http://sacsis.hpcc.jp/2011/files/SACSIS2011-Tutorial-1-pub.pdf 11
12. 次世代不揮発性メモリ (Persistent Memory, PM) 特徴 ▪ 低レイテンシ (~DRAM) ▪ load/store命令による バイト単位のアクセス(Byte-Addressability) Volatile Durable Persistent Memory 12 fig) http://www.hlnand.com/site/ID/applications Durable(PM) 3D XPOINT (Intel and Micron) http://newsroom.intel.com/docs/DOC-6713
13. Byte Addressability ▪ Disk: read/write API ▪ PM: load/store instructions Difference between PM and Disk 13 fig of HDD/SSD) http://storage-system.fujitsu.com/jp/lib-f/tech/beginner/ssd/ load/store to DRAM read/write to SSD/HDD load/store to PM Non-volatile Data Cache Per Sector (4k or 512 bytes) Per Byte (1 byte)
14. Design Spaces on PM 低レイテンシ V-NV gap is coming up between cache and PM 高いランダムアクセス性能 ▪ read/write API are not suitable for PM ▪ Other data structures based on disk are the same 14
15. ファイルシステム (FS) 不揮発データの管理を行うためのシステム ▪ FS上ではデータはファイル単位で管理 ▪ ユーザープログラムは mmap/writeといったAPIを使ってデータにアクセス 15 PM上のデータも ファイルシステムで管理されると考えら れる
16. 既存のファイルシステムの2つの問題点 データの整合性 ▪ 書き出しタイミングをユーザーは定義しないことにより、 障害時に中途半端な状態で永続化されてしまう可能性 ▪ データの整合性を担保するためには複雑な操作が必要 ブロックデバイス前提の設計 ▪ レイテンシを隠蔽するためのキャッシュを介する前提の設計 ▪ PMの導入により、レイテンシが大きいという前提が変化 16
17. 既存のファイルシステムの2つの問題点 データの整合性 ▪ 書き出しタイミングをユーザーは定義しないことにより、 障害時に中途半端な状態で永続化されてしまう可能性 ▪ データの整合性を担保するためには複雑な操作が必要 ブロックデバイス前提の設計 ▪ レイテンシを隠蔽するためのキャッシュを介する前提の設計 ▪ PMの導入により、レイテンシが大きいという前提が変化 17
18. 書き出しタイミングの問題 単純なプログラム 整合性を保ったプログラム 18 {timestamp: 2015/05/01 16:00:01, value: 100} hoge.dat (expected) data_t *data = mmap(hoge.dat); data->timestamp = now(); data->value = somefunc(); {timestamp: 2015/05/01 16:00:01, value: 5615467685} hoge.dat (corrupted) ts = now(); val = somefunc(); cs = checksum(ts, val); creat(log.dat); log = mmap(log.dat); log->timestamp = ts; log->value = val; log->checksum = cs; msync(log); data = mmap(hoge.dat); data->timestamp = ts; data->value = val; msync(data); munmap(log); close(log.dat); unlink(log.dat); アトミックな永続化を行うためには 複雑な操作を行う必要がある 障害(電源喪失など)の発生により データの一部だけが永続化される可能 性 解決するためには？: アトミックな永続化 ディスクアクセスを発生させるために従来はコストが高かっ たが、PMだと低コストで利用が可能となる
19. 既存のファイルシステムの2つの問題点 データの整合性 ▪ 書き出しタイミングをユーザーは定義しないことにより、 障害時に中途半端な状態で永続化されてしまう可能性 ▪ データの整合性を担保するためには複雑な操作が必要 ブロックデバイス前提の設計 ▪ レイテンシを隠蔽するためのキャッシュを介する前提の設計 ▪ PMの導入により、レイテンシが大きいという前提が変化 19
20. 既存のファイルシステムの2つの問題点 データの整合性 ▪ 書き出しタイミングをユーザーは定義しないことにより、 障害時に中途半端な状態で永続化されてしまう可能性 ▪ データの整合性を担保するためには複雑な操作が必要 ブロックデバイス前提の設計 ▪ レイテンシを隠蔽するためのキャッシュを介する前提の設計 ▪ PMの導入により、レイテンシが大きいという前提が変化 20
21. ページキャッシュを介したアクセス 既存のファイルシステム ▪ DRAM上のページキャッシュを介したデータアクセス ▪ レイテンシが大きいデバイスでは有用だが、 ブロック単位での読み書きが前提となっている 21 1: ページキャッシュの確保 2: ページ単位での転送 3: ユーザーバッファへのコ ピー 0: read(fd, buffer);
22. 望まれるPMとのアクセス PM向けのファイルシステム ▪ PMはレイテンシが小さく、構造上バイト単位の書き換えが可能 ▪ ページキャッシュをなくし、直接読み書きを行うことが考えられる 物理アドレスを持つため、load/store命令で直接読み書き可能 22 User Applications PM Page Cache (DRAM) Block Device MMU mmap mmap Common File Systems PM向けFS
23. ２つの問題を解決するにあたって… 整合性 ▪ ファイルシステムでアトミックなデータの永続化をサポート ▪ そのために、データをバックアップするようなプロトコルが必要 PMへの直接のアクセス ▪ load/store命令を用いて直接データを編集 ▪ 直接本体のデータへ編集すると、整合性が保たれない その他にも… ▪ 従来通り整合性を確保するためのライブラリなどを用いるとすると、 load/store命令を関数呼び出しでラップする必要がある ▪ 関数呼び出しによるオーバーヘッドは大きいと考えられる 23
24. AMFS (Atomic File System) 24 整合性と直接のアクセスを両立したファイルシステム ▪ アトミックなデータ永続化のOSレベルのサポート fbegin()の導入による容易な記述を実現 ▪ load/store命令によるPM領域へのアクセスのサポート PM向けページキャッシュ手法: Read-through/Write-back fbegin(hoge.txt); data = mmap(hoge.txt); data->timestamp = now(); data->value = somefunc(); fsync(hoge.txt); ts = now(); val = somefunc(); cs = checksum(ts, val); creat(log_fd); log = mmap(size, log_fd, …); log->timestamp = ts; log->value = val; log->checksum = cs; msync(log_fd); data = mmap(size, data_fd, …); data->timestamp = ts; data->value = val; msync(data_fd); munmap(log_fd); close(log_fd); unlink(log_fd); fbegin() の導入による アトミックなデータ永続化のサポート
25. 使用例1: mmap ふつうにmmapぽく使うけど安全に更新できる 25
26. 使用例2: malloc mallocのインターフェースでもっと簡単に利用出来る例 (実はどっかでmmapをつかっている) 26
27. 使用例3: KVSとしてstd::mapを利用 27
28. 使用例4: named malloc これはまだ実装できていない…けどあると絶対いいだろ！というもの 28
29. まとめ いろいろなハードウェアが開発されている ▪ これまでの10年での進歩のように、これから10年も進歩していく ▪ それに応じてソフトウェアも追従する必要がある！ AMFS ▪ そんなものの一つ。そして僕の修論のテーマ。 ▪ 今後のファイルシステムは次世代不揮発メモリ (PM) のSSDの1000倍速いと も言われる性能を活かしていくAPIが必要 ▪ 安全にファイルの更新も行えるような設計 ▪ そしてバグの元に死nげっふんgefun ▪ PMFSの後継はいまLinuxのmainlineにも入っていて激アツいので、興味あっ たら是非追いかけてみてください^^ 参考: https://nvdimm.wiki.kernel.org/ ▪ そのうちAMFSも公開できたらいいな … 29
30. PM-Aware Page Cache Scheme Is Page Cache Needed for PM? (again) Traditional File Systems ▪ Copy data to page cache in a page granularity ▪ Effective for non byte-addressable, high-latency devices (ex: HDD/SSD) but for PM…? 30 No latency improvements just make a redundant copy! Writes should be cached due to rewrite cycle limitation Caching for PM should be Read through / Write back!
31. PM-Aware Page Cache Scheme Step 1: Read Through Read through/write back caching scheme 1. OS maps PM as read-only virtual address space 31 Virtual Address Space DRAM Storage(PM) Read Read through
32. PM-Aware Page Cache Scheme Step 2, 3: Create a Cache Read through/write back caching scheme 1. OS maps PM as read-only virtual address space 2. DRAM cache is assigned when user writes data 3. The virtual address is remapped to DRAM cache 32 Virtual Address Space DRAM Storage(PM) Write
33. PM-Aware Page Cache Scheme Step 4: Atomic Durability (CoW) Read through/write back caching scheme 1. OS maps PM as read-only virtual address space 2. DRAM cache is assigned when user writes data 3. The virtual address is remapped to DRAM cache 4. fsync persists the data atomically 33 fsync() Virtual Address Space DRAM Storage(PM) CoW!! Write back
34. PM-Aware Page Cache Scheme Two Strengths: Rewrite cycles Strengths ▪ Mitigate the write cycles ▪ No page fault for reading 34 AMFS Virtual Address Space DRAM Storage(PM) Write
35. PM-Aware Page Cache Scheme Two Strengths: No page fault Strengths ▪ Mitigate the write cycles ▪ No page fault for reading 35 Virtual Address Space DRAM Storage Read Current mmap
36. PM-Aware Page Cache Scheme Two Strengths: No page fault Strengths ▪ Mitigate the write cycles ▪ No page fault for reading 36 Virtual Address Space DRAM Storage(PM) Read AMFS