Changeset d3973ef in lab.git for Commentary/kernelvm/20130413.log


Ignore:
Timestamp:
Apr 13, 2013 3:22:24 PM (12 years ago)
Author:
mitty <mitty@…>
Branches:
master, trunk
Children:
de9540b
Parents:
04eb6d7
Message:
  • memo for 8th Kernel/VM expedition
  • add about Fusion-io

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

File:
1 edited

Legend:

Unmodified
Added
Removed

  • Commentary/kernelvm/20130413.log

    r04eb6d7 rd3973ef  
    294294 
    295295 
     296@fusioniojp 
     297FUSION-IO関連の楽しいお話 
     298    IOMEMORY SDKとNVMインターフェース 
     299        Non Volatile Memory 
     300    NANDフラッシュメモリとDMAコントローラを一体にしたもの 
     301     
     302    現行 
     303        NANDとメインメモリの間にI/Fのコントローラが挟まっていて、遅い 
     304            SASコントローラなど 
     305    これから (カットスルーアーキテクチャ) 
     306        FPGAで実装されているデータバスコントローラを使う 
     307        メインメモリに直接コピーされる 
     308    512byte -> 10usで書ける 
     309    HPCではデータをHDD上に置かない 
     310    SSDが出てきた時、「NANDはメモリなんだから、メモリのようにI/O出来るようにすべきだ」 
     311    不揮発メモリであれば、BlockI/Oでは実現出来ないような操作が可能 
     312        BlockI/Oは回転型メディアにあわせて設計されている 
     313        テープ 
     314            open/read/write/rewind 
     315        ディスク 
     316            open/read/write/seek 
     317        SSD 
     318            ディスクと同じ様にあえてしている 
     319            Trimとかは一応あるが…… 
     320        ioMemory NVM 
     321            不揮発メモリの特性を生かした追加機能 
     322            通常のライト＋アトミックライト・条件付きライト 
     323                ジャーナル要らなくね？ 
     324            通常のライト＋TTLライト(のちに自動消去) 
     325                このデータは自動的に消滅する 
     326            mmap＋クラッシュセーフ・バージョニング 
     327                先ほどのftraceの様にどんどんログを書き込む 
     328    SSDの登場により、フラッシュメモリを使ったアプリケーションが実現した 
     329        フラッシュメモリをメモリとして利用すると、ソフトウェア開発のあり方が変化する 
     330    現行 
     331        アプリケーション -> BlockI/O、ネットワークファイル 
     332    これから 
     333        アトミックI/O 
     334        トランザクション 
     335        ユーザ定義のオブジェクトによりトランザクション 
     336        Key-Valueトランザクション 
     337            memcached 
     338    将来 
     339        高速なロギング 
     340        チェックポイントメモリ 
     341        メモリトランザクション 
     342        CPUからメモリに書き込むように、フラッシュメモリに書き込める 
     343    100万IOPSのカードは既に実現している 
     344        CPUのコンテキストスイッチの方が問題になってくる 
     345        -> mmaped I/Oすれば良いのでは 
     346    64byte/1thread -> 960万回 
     347    スパースアドレス空間 
     348    デバイスI/Fのオープン化と、OSS 
     349        directFS 
     350        NVM APIライブラリ 
     351        Atomic writeはSCSI標準化に向けてプロポーザルを出した 
     352    ハードウェア側で書き込みを保証出来るので、アプリケーションとしては単に「書き込む」だけで良い 
     353        MySQLのダブルバッファーのようなことは必要なくなる 
     354        書き込み量が減るので、製品の寿命も長くなって良い 
     355    書き込みの粒度を512byteから小さくすれば、一回の書き込みに掛かる時間は短くなる 
     356    directFS 
     357    swap -> Extended memory 
     358     
     359    Q/A 
     360        ウェアレベリングなどはどこで行われているか 
     361            CPU側で行っている 
     362            SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが 
     363            ブロッキングされるより、CPUで行った方が結果として早かったりする 
Note: See TracChangeset for help on using the changeset viewer.