* memo for 8th Kernel/VM expedition
authormitty <mitty@7d2118f6-f56c-43e7-95a2-4bb3031d96e7>
Sat, 13 Apr 2013 06:22:24 +0000 (06:22 +0000)
committermitty <mitty@7d2118f6-f56c-43e7-95a2-4bb3031d96e7>
Sat, 13 Apr 2013 06:22:24 +0000 (06:22 +0000)
 * add about Fusion-io

git-svn-id: https://lab.mitty.jp/svn/lab/trunk@208 7d2118f6-f56c-43e7-95a2-4bb3031d96e7

Commentary/kernelvm/20130413.log

index 4350d9d..f23f395 100644 (file)
                        日本ではMAKEというイベントに行けば見れるかも
 
 
+@fusioniojp
+FUSION-IO関連の楽しいお話
+       IOMEMORY SDKとNVMインターフェース
+               Non Volatile Memory
+       NANDフラッシュメモリとDMAコントローラを一体にしたもの
+       
+       現行
+               NANDとメインメモリの間にI/Fのコントローラが挟まっていて、遅い
+                       SASコントローラなど
+       これから (カットスルーアーキテクチャ)
+               FPGAで実装されているデータバスコントローラを使う
+               メインメモリに直接コピーされる
+       512byte -> 10usで書ける
+       HPCではデータをHDD上に置かない
+       SSDが出てきた時、「NANDはメモリなんだから、メモリのようにI/O出来るようにすべきだ」
+       不揮発メモリであれば、BlockI/Oでは実現出来ないような操作が可能
+               BlockI/Oは回転型メディアにあわせて設計されている
+               テープ
+                       open/read/write/rewind
+               ディスク
+                       open/read/write/seek
+               SSD
+                       ディスクと同じ様にあえてしている
+                       Trimとかは一応あるが……
+               ioMemory NVM
+                       不揮発メモリの特性を生かした追加機能
+                       通常のライト+アトミックライト・条件付きライト
+                               ジャーナル要らなくね?
+                       通常のライト+TTLライト(のちに自動消去)
+                               このデータは自動的に消滅する
+                       mmap+クラッシュセーフ・バージョニング
+                               先ほどのftraceの様にどんどんログを書き込む
+       SSDの登場により、フラッシュメモリを使ったアプリケーションが実現した
+               フラッシュメモリをメモリとして利用すると、ソフトウェア開発のあり方が変化する
+       現行
+               アプリケーション -> BlockI/O、ネットワークファイル
+       これから
+               アトミックI/O
+               トランザクション
+               ユーザ定義のオブジェクトによりトランザクション
+               Key-Valueトランザクション
+                       memcached
+       将来
+               高速なロギング
+               チェックポイントメモリ
+               メモリトランザクション
+               CPUからメモリに書き込むように、フラッシュメモリに書き込める
+       100万IOPSのカードは既に実現している
+               CPUのコンテキストスイッチの方が問題になってくる
+               -> mmaped I/Oすれば良いのでは
+       64byte/1thread -> 960万回
+       スパースアドレス空間
+       デバイスI/Fのオープン化と、OSS
+               directFS
+               NVM APIライブラリ
+               Atomic writeはSCSI標準化に向けてプロポーザルを出した
+       ハードウェア側で書き込みを保証出来るので、アプリケーションとしては単に「書き込む」だけで良い
+               MySQLのダブルバッファーのようなことは必要なくなる
+               書き込み量が減るので、製品の寿命も長くなって良い
+       書き込みの粒度を512byteから小さくすれば、一回の書き込みに掛かる時間は短くなる
+       directFS
+       swap -> Extended memory
+       
+       Q/A
+               ウェアレベリングなどはどこで行われているか
+                       CPU側で行っている
+                       SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが
+                       ブロッキングされるより、CPUで行った方が結果として早かったりする