koie blog : いってきた: MemoryPlus Workshop

MemoryPlus Workshop -- メモリとファイルストレージとOSと --
2014-09-17 10:00-18:45
JAIST 品川サテライトオフィス (品川インターシティー 19F)
主催: JST CREST「ポストペタスケール時代のメモリ階層の深化に対応するソフトウェア技術」研究チーム
http://aml.hpcc.jp/swopp-announce/msg05082.html

オープニング / 遠藤敏夫 (東工大)

別名緑川勉強会
帯域と容量の両立はむつかしい→階層化
- HMC-NVRAM-Flash

[2014-09-17 10:13]

NAND型フラッシュメモリーとSSD / 菅野伸一(かんのしんいち) (東芝)

会場挙手アンケート:
- SSD利用用途: ファイルシステムが多い・ワークエリアにつかう人ももそこそこいる。
- 誤り訂正方式: しってる人はほとんどいない。(でもしっている人が数人いることに驚きだ)
- write ampification、over provisioning: などのキーワードを知っている人もそこそこいる。
NANDはトランジスタ自体を配線としてつかって高密度化
MLCは (0,1) (0,0) (1,0) (1,1) になっている(グレイコード)。1レベルの誤りで2ビットの誤りにならないようにする工夫。
ブロックの大きさ: いまどき8GB〜16GB? (ききまちがえだとおもう)
ページ: ブロックに126個くらい
内部では16KB単位で。4Kでも性能は16KBの性能になってる。
テンポラリー用途なら(1年もデータを保持しなくてよいので)寿命は伸びる。
東芝製品はウェアレベリングは積極的にやらない。逆にインテルは積極的にやってるようだ。
最終的に寿命が尽きるときにウェアレベリングできていればよいという考え。
SSDコントローラのDRAMのほとんどをLUTがほとんどつかっている。キャッシュはOSがやるのでSSDでやる必要なし。
オーバプロビジョニング: コンシュマ7% エンタープライズ37%
write apmplification: 1データをかいたときにN書き換え。
客が4Kのベンチマークをしてくる。困る。
- DRAMサイズがおおきくなる。
Tips
- TRIMは過信しない
- デフラグはワークロードがかわったタイミングでやると、GCがよくなって、トータルで特することもある。自分のPCでは3ヶ月に1回くらいやる。

[2014-09-17 10:53]

Q:デバイスのDRAMキャッシュが効かないのは？
A:サイズのミスマッチ。小さすぎる。
Q:pseudo SLCはやってる
A:やってる製品もある.
Q:3D-NAND
A:ブロックサイズが極端に大きくなる。
Q:IOPSに効くのは？
A:readはLUTの性能、writeはwrite amplification

[2014-09-17 10:56]

Massive Capacity SMR Disk and Their Impact on Host System Software / Damien Le Moal (HGST)

最近は高速HDDはつかわず大容量HDDに直接アクセスすることがおおい。(Facebookなど)
SMR: トラックがかさなる。trackNを書くとtrackN+1がoverwriteされる→シーケンシャルライトしかできない。その代りに容量が3倍になる。
SMRのターゲット: アーカイブ(テープとふつうのHDDの中間)
シーケンシャルライトしかできないがファームウェアでがんばって(indirection,GC)ランダムライト可にできる。
T10: SCSIの規格では ZBC(zoned-block command).
T13: SATAの規格では ZAC(zoned-device ata command).
どちらもコマンドは同じ。
- model: autonomous(ランダムライトできる), host-aware(ランダムライトできるが最適化はホストでやれ), host-managed(そもそもデバイスタイプがちがう).
zoneはLBAのレンジで指定される。大きさは自由。規格でも決められていないしzoneごとにサイズが違う可能性もある。先頭と最後のゾーンがconventionalである保証はない→MBRとか置けるとは限らず。
zone type: conventional zone, sequential write preferred, sqeuential write only.
ゾーンごとにwrite pointerがある。
コマンドは2つだけ: REPORT ZONES, RESET WRITE POINTER. (10ページくらい)
ランダムリードはゾーンの先頭からwrite pointerの前まで。後ろを読むとエラーになる。
アプリケーションから直接デバイス(SG_IO)をたたくとページキャッシュなどのサポートがなくなる。
カーネルでサポートするなら
- 論理ストレージデバイスを設けるか
- ファイルシステムを設計するか
- log-structured FSみたいなのにするか
- block IO schedulerはzone-awareにしないといけない。
ファイルステムは安定性の面から心配(安定するまで時間がかかる)なのとSMR専用のファイルシステムになってしまうので避けたいところ。
sg_util, libzbc, device type 14,
来年にはデバイスが出回るけど、カーネルの対応はまったく進んでない。
fsはhost-awareで。ブロックアロケーションをfsからブロックレイヤーにもっていく提案がでてきている。
来年でてくるのはhost-awareのもの(autonomousのはしばらくかかる)

[2014-09-17 11:23]

Q: OSは？
A: まずはlinux. SMRはコンシューマ向けではないのでwindowsはないだろう(windows serverならあるかも?)。じつはSMRになっているHDDが出まわっている(性能はプチフリがある)。
Q:テープとしてつかうのは?
A:アーカイブコストとしてはテープに比べ苦しいところ。facebookの写真などは向いているだろう。writeスループットはふつうのHDDよりも遅い。トラックピッチが狭くなるのでトラックNをライトしたらN-1のトラックをverifyする必要があって遅い。(N-1のトラックを書き潰してしまっている恐れがあるため)
Q:ディスクアレイだとどう？
A:LHC(加速器)などは向いているかな。HPCだとあまり向いてない? Host-managedは特殊なモデルでHost-awareがつかわれるだろう。
Q:ゾーンのサイズは?
A:ディスク内でバラバラでもよいことになっている規格では。皆の希望は小さめ。

[2014-09-17 11:33]

[2014-09-17 11:34]

Linuxのページ回収処理のよる高性能計算アプリケーションへの影響 / 大山恵弘 (電通大)

データインテンシブサイエンス： IOウォール問題。世界最高でいまのところ1TB/sくらい。
NUSA: non unified storage architecture: 5年後に100TB/sにしたい。
OSジッタ: HPCで悪影響をあたえる。割り込み処理とかデーモンとか。同期がズレて性能が落ちる。古い問題だが今でも論文が出ている。
大規模データをIOするとページキャッシュの操作がはいる→OSジッタ
(今回の話はNVRAMとは関係ない)
メモリがたりなくなったら： direct reclaim か kswapdを起こすか。pdflushはダーティページを書き出すもので今回の話とはちょっとちがう。
共有ページフレームを回収するときはすべてのPTEを一度に削除
ページ回収という名の闇または沼! 職人の世界。
ページをたくさん消費しているとkswapdは頻繁に解放処理する。一度に解放するページ数は少なめ。
high water mark -- low water mark -- min water mark がある。
kswapdよりも先に新しい回収デーモンを起こして、ページを一気に回収することで、処理コストを抑える。
- ディスクアクセスが多ければキャッシュを解放するなど。
WRF
コア分離: デーモン用にCPUコアを割り当ててしまう解決方法。デーモン用にCPUコアをどれだけ空けておけばよいかわからないので、そもそものジッタを減らす努力が必要。

[2014-09-17 12:02]

Q:swap deviceは? Flashだとどうなる？ directIOつかえば？
A:HDD。swapはしてない。ページキャッシュの回収コスト。directioは検討したがread-aheadを自前でやらないと性能が落ちることもあり、アプリ開発者の負担が増える。
Q:メモリのcgroup。flexsc。
A:ファイルアクセスだとcgroupは効きにくい。cgroupのオーバヘッドは大きめ。(そんなに重くないという声が会場から)
Q:drop_caches。madviseのDONTNEEDのようなのがページキャッシュにあればよい？ DONTNEEDはすぐにフリーリストにのるはず。
Q:まとめて回収することで性能が改善した？
A:回収したページ量は同じ。こまかく回収するところにコストがあるようだ。

[2014-09-17 12:12]

ひるやすみ

ビル内のつきじ植むらで、日替わりのつめたいうどんと生姜焼きだったかなぁ780円。

[2014-09-17 13:11]

Linuxのメモリ管理 / 吉田雅徳 (日立)

Page Frame = page-sizeでかつアラインされているもの。
ACPI: SRAT(static resource affinity table), SLIT(system locality table)
Zone: DMA(0-16M), DMA32(-4G), NORMAL(4G-), MOVABLE(hot plug memory向け)
ゾーンに分けているのは低位アドレスを特定デバイス向けに使いたいため(希少資源)。
dirty ratio: 未書き込みのページが増えすぎないようwrite backする閾値。
zone list: より高位のゾーンから割り当てるか(zone)、同じノードから選ぶか(node)、zone_normalとzone_dmaのサイズが同じくらいの容量だったらnodeポリシーで、normal>dmaならzoneで。
kswapdはnumaノードごとにある。low watermarkをしたまわるとkswapdが動く。page allocationは止まらない。minまで少なくなるとallocationが止まってdirect reclaimがうごく。
buddy system: 連続したページごとにまとめて管理する。4Kのアロケーションが圧倒的に多いので最適化がされていてCPUごとにキャッシュが用意されてホット(cpu cacheに載っているだろう;通常利用のページ)/コールド(載っていなさそう;DMAでつかったとか)が管理である。
active_listのなかにinactiveがないかどうか調べて、inactive_listをページアウトできるかどうか。
laptopの場合はactive->inactiveに移動させるときにcleanなページかどうかチェックが入る。ディスクを動かしたくないため。
KSM(kernel shared memory): たまたま内容が一致したページを共有する機能。stable_nodeに複数のanon_vmaがぶらさがっている。
VFS(Various FS): 抽象化: superblock, dentry, inode, pagecache
filep->dentry->inode->page
block cache = attribute + page cache
- メタデータのページキャッシュはデバイス(/dev/sda)でつくられている。
- 最近の速いデバイスではbio ioスケジューラを経由せずデバイスドライバを直接呼んでいる。(Le Moal Damien談)
NVM
- Block Device: NVMe(express) いくつかのレイヤをふっとばす
- Persistent Memory: PMFS(tmpfs似), DAX(direct access block layer)(EXT4をDAXの上にのせるとpage cacheなしにIOする)。
- DAX: ext2のXIP(eXecution In Place;キャッシュなしにデバイスを直接マップ)をext4に移植したもの

[2014-09-17 13:48]

Q: NVMの開発は? エラー訂正が必要ならブロック単位にならざるをえないが。
A: RAMでエミュレーションしながらやっているようだ。
Q: NVM PCIプロトコルが重くて半分くらいしか性能が出ない。
Q: レイテンシは?
A: わからない。
Q: read/writeの性能の非対称性はどのくらい問題になる？
Q: NVMはどのあたりで使われる？
A: しらない。

[2014-09-17 13:56]

不揮発メモリ向けファイルシステムの設計 / 建部修見 (筑波大)

計算科学: 初期値の読み込み(100TB-PB)、スナップショット(約1時間間隔)書き出し(100TB-PB)
データインテンシブサイエンス: 実験データ(10PB-EB)
並列ファイルシステムへの性能要求
- IOバンド幅とIOPSはコア数に比例することが想定される。
- 100TB/s 1Miopsをめざしている
HDDの性能はほとんど向上しない。100TB/sの性能を出すには2MWもHDDで使ってしまうことに。それはシステム全体から見て多すぎる。
フラッシュなら1GB/sで0.1W。(菅野:1桁くらい小さいすぎない?)
ハイブリッド(NVM-HDD)にしてもネットワークバンド幅制限は解消されない。
バーストバッファ(IOフォワーディング・IOデレゲーション): 計算ノードに高速ストレージをもってくる。
計算ノードにストレージを分散させる。(共有メモリが分散メモリになったように)
- 分散メモリがうまくいっているのはアプリがMPIをつかているから。でも同じように分散ファイルをユーザにみせてしまうとそれは面倒すぎる。ユーザがファイルの管理(=メタデータ管理)をしないといけない。
オブジェクトストア
- ファイルシステムとディスクの中間的なもの。
- ファイルシステムのメタデータの管理コストが下がる。
OpenNVM
- アトミックバッチ:nvm_batch_atomic_operation(IOベクトル)
- スパースアドレス:flash translation layer(FTL)の提供
- キーバリュストア: nvm_kv_put/get
HDDはシーケンシャルアクセスで性能向上 → NVMは並列アクセスで性能向上の違い。
persistent trim: fusionIO由来、TRIMするとデータがすぐ消える。(通常のtrimはヒントでしかない)
NVMによるオブジェクトストアの例
- リージョンを大きくとる。
- 固定長にするとIDと直接対応。
- persistent trimとスパースアドレスとでリージョンは使い捨てにできる。

[2014-09-17 14:27]

Q: fusionIO
A: そのもの
Q: IOが速くなると相対的にCPUの負荷があがってくる。
A: HPCだとメモリバンド幅で上限があるので1コアくらいOSで専有できるだろう。カーネル専用コアとか.
Q: オブジェクトストアでFTLをとばしてダイレクトアクセスしないのか？
A: こまかいアロケーションするので必要
Q: openNVMは1デバイスを仮定しているがスケーラビリティは？
A: MDSのスケールアウトが鍵
Q: そもそもファイルにする必要はないのでは？
A: hadoopなどのインタフェースで考えるのもあり。

[2014-09-17 14:34]

[2014-09-17 14:35]

Linuxにおける不揮発性メインメモリとストレージの融合とその応用 / 及川修一 (筑波大)

NVM: linuxではパーシステントメモリとよばれている。
今はまだCPUに直結はできないようだが、メインメモリとして使えるとして考えてみた。
ファイルシステムとメインメモリの両方として使ってみたら？
既存のメモリファイルシステムはカーネルとくっつきすぎていて使いにくい。(カーネル構造体をそのままつかってたり。バージョン間の互換性がないファイルシステムはいやだ)
XIPをつかうことに。
anonメモリをallocateするのをfilesystem経由でNVMをとってくる。
PRAMFSはいじくりやすい。
NVMをつかうと、高機能なfsが遅かったり、bitmap操作が遅かったりするのが見えてくる。
チェックポイント・リスタート
- メモリをファイルにできる。コピー不要。
- カーネルの再起動が若干速くなる。
- リスタートするとファイルが壊れるがCoWにしとけばok。
kernel rejuvenation(若返り)
- カーネルだけリスタートしてシステムを安定にするというやつ。
wikipedia: Everything_is_a_file
NVMを搭載したマシンがこうなるであろうというコンセンサスがないので論文書きにくい。現実味がないとしてrejectされてしまう..
NVMの性能を反映できるcycle accurate simulatorはすごく遅い..
インテルはCPUをいじって特定の領域だけレイテンシをかけることでエミュレートしているらしい。
Open SSD

[2014-09-17 15:09]

Q:filesysとmem、どっちを生かすか？
A:メモリの沼にははまりたくなかったのと、カーネル構造体に依存してしまうので別のカーネルから使えないので、ファイルシステムにした。 gmpfs?
Q:メモリとファイルの量的切り分け
A:固定
Q:メモリアドレスを仮想化するとうれしい?
A:かんがえてなかった。
Q:struct pageをファイルとメモリの両方に用意しているがintelは片方だけだが？
A:いってることはわかる。そこまでNVMがたくさんのは考えてないので問題ない。
Q:NVMとCPUのキャッシュと電源断 (write-throughになってればいいけど)
A:H/Wでがんばってはきだすのが正しい。

[2014-09-17 15:18]

休憩

[2014-09-17 15:26]

不揮発性メモリを考慮した大規模なグラフの高速処理 / 佐藤仁 (東工大)

tsubameのストレージの設計などをしているが、あえてアプリの話を。
大規模グラフ処理はスパコンの重要なコアだと考えられるようになった。
- graph500: スケールフリー・スモールワールド: kronecker graphをBFSする。
EUでやってる脳シミュレーションだとgraph500 hugeくらいの規模になる。
BFS: conventionalなtop-downなのと(2012年)bottom-upなのと。
- ハイブリッド: 探索済の頂点数でtop-downかbottom-upなのかをきりかえる。
非同期IOとかmmapとかopenNVMをつかってみたが、性能改善はアルゴリズムの方が効いた...
構成はRAIOD0でSSDぶらさげてPCIe x8で。fusionIOには劣るが安い。
DRAMに載りきらずSSDの60%くらいをつかうようになっても、それほど性能は落ちず。
DRAMをつかえばつかうほど性能が落ちてSSDをつかった方が性能が出た→ページ回収のコストか?
HAMAR: GPUとSSDを直接つなぐ

[2014-09-17 16:00]

Q: 京と今回のハイブリッドシステムのアルゴリズムの違いは？
A: たいして違わず。以前は1/3くらいの性能しか出てなかったが、ハイブリッドでほぼおなじになった。京だとネットワークのコストがかかってくるのでチューニングちがってくる。
Q: SSDインタフェースは?
A: ふつうのファイルIO。直接SSDをたたいてもせいぜい20%くらいしか向上しないと見込んでいる。
Q: 不揮発性はどうでもよかった？省電力ならよかった？
A: スパコン側からしてはメモリのコストと量が気になる。不揮発性は耐故障性の面では必要かもしれない。
Q: スケール30以上のニーズは本当にあるのか？30以下の方がニーズがあるのでは？
A: たしかにノード数少なくて省電力の方が需要がある。巨大なグラフの実データがない。twitterでやっと2^30くらい。もっと儲かるアプリからカーネルをもってきたほうがいいかも。

[2014-09-17 16:09]

[2014-09-17 16:10]

格子系アルゴリズムの局所性向上とHHRTライブラリの実践 / 遠藤敏夫 (東工大)

GPUからPCIex経由でホストのメインメモリにアクセスできる。
テンポラルブロッキングによる局所性向上
- 時間発展を小さい空間ブロックで進めることで局所性向上。→ アプリケーションが難しくなる。
プログラミングコスト重視
- 自動でテンポラルブロッキングに変換するのはムリだが
- できるところだけ自動でやる → Hybrid Hierarchical RunTime

[2014-09-17 16:24]

[2014-09-17 16:25]

Exanaツールによるメモリアクセスプロファイリング / 佐藤幸紀 (JAIST)

ダイナミックコンパイラ：ループアンローリングを動的にやる。
Exana: EXecution-driven application program ANAlysis Tool set
- ループ構造解析
- データ依存性解析 (タスク並列性がわかるとか)
- 関数インライン展開されてもデバッグ情報から対応づけ
- BytePerFlops ratio: 手動計算に近い値が得られた。
- LiwkidだとCPUからメモリに出ていくところをカウントするのでBFratioは低くなる。
- アクセスパターンのパターン化 (fix, sequential, stride, sequential-stride, それらの組み合わせ(再帰的)) して解析
  - アクセストレースは大きくなる→パターン化するとコンパクトに→階層化するとずっとコンパクトに

[2014-09-17 16:42]

[2014-09-17 16:43]

Flash SSD利用による大規模ステンシル計算 / 緑川博子 (成蹊大)

fusion iodrive2 mlc: HDDよりは1000倍くらい速いがDRAMよりは1000倍くらい遅い → 単にmmapしただけではダメ。
spatial blocking と temporal blocking と two-level..: メモリに載りきらなくてもけっこう動く。
aioを効かせるにはアラインしてないとだめだけど、そろっているとTLBとかメモリバンクコンフリクトしてCPU計算が遅くなってた。
aioは大きなIO単位でアクセスしてるのにiostatでみてると細切れになってる。。

[2014-09-17 17:01]

休憩

[2014-09-17 17:11]

パネルディスカッション

緑川・菅野・Le Moal・大山・建部・追川・佐藤・遠藤 (会場:松岡)
DRAMとflashの間には2つくらい階層が必要なのでは？
HDD/Flashはスロット的にあまり増やせないのでアーキテクチャに問題がある。
計算とストレージを分ける方向性もある。
デバイスやってる人はDRAMをNVMが置き換えるとはりきっている。そうなるとOSからファイルがなくなってmallocになる。
SLCとMLC、値段は2倍、寿命は10倍。
ハイバネーションの調査は社内調査したことがある。結果は十分もつことがわかった。
MRAMにきりかわるかどうかは値段できまる。パワーの問題もある。
MRAM: DRAMとflashの間をうめたいという客はあまり声がきこえてこない。
ReRAM:記録原理がまだよくわかってない。
東芝DRAM 25年持つのをつくっていて5年で不良がでるメーカーに負けたので寿命にはセンシティブ
メモリの消費電力自体はシステム全体では小さいのでは？
IOPS/powerで考えるべき。ラックの電力や電力密度も考えるべき。
google big query: 1ノードにHDD10台ぶらさげてインターコネクトも謎。
HPCはbigdataデータセンターにとりこまれていく。
facebookは初期からPCI SSDをいれていたのは、そうしないとさばけないため。1要求で10メッセージくらいとぶ。
GPU/FPGA: azul たまたまハーフラックに入るGPUはいまいちパワーがないため。baiduはGPU。HPCのネットワークをどうやってIDCに低コストでいれていくか。
今のHDDは複数プラッタになっていても並列には処理されてないらしい。
NAND 3D stack になるとビットクロスがおきてHDDが負けるがなくなりはしない。長期保存向け。
松岡: MRAMよりもReRAM? MRAMはDRAMとflashのあいだに、ReRAMは大容量にいく？
メモリの信頼性はどのくらい必要なのか？ 1byteのなかの1bitエラー訂正するのに4bit必要。最小アクセス単位が1KBとかになればコストがちがってくる。
キャッシュラインサイズ64Bでアクセスできればよい。
1つのデバイスに要求される信頼性が異なるデータが混在している。昔はテープは頻繁にコピーしていた。
エンタープライズでSATAをつかうようになるのに8年くらいかかった。カップリングの問題もある。
インメモリデータベースでも小さいアクセス単位でしない。データは数バイトでもレコードはKB。しかもベクトルでなめるので。
インメモリデータベースでも正規化されてないとレコードはでかい。
バイトアクセスできてもアプリが性能を出すためには、きれいにならべておくひつようがある。
2012のSACSISでMRAM数年のうちに出るって産総研の人がいってたけど、、、
HPの人がthe computerというのをやってる？メモリ階層は深くなるより浅くなる？
素子が同じでも物理的な距離の制約があるので、そんなに単純ではない？
メモリ圧縮の話は？メモリ階層をあつかえるガーベッジコレクション・コンパクション。東芝SSDはコンシューマ向けのは書き換え頻度が高い部分を速いブロックに書くようになっている。エンタープライズでは均一なアクセスを要求しているので向かない。エンタープライズの人は自分のコントロールできないレイヤがあるのが嫌い?
組込み向けのGCではアクセスパタンによって置き場所を変えるという研究はある。