More Related Content Similar to 不揮発メモリ(NVDIMM)とLinuxの対応動向について(for comsys 2019 ver.) (20) 不揮発メモリ(NVDIMM)とLinuxの対応動向について(for comsys 2019 ver.)1. Copyright 2019 FUJITSU LIMITED
不揮発メモリ(NVDIMM)と
Linuxの対応動向について
(for comsys 2019 ver.)
2019/12/11
富士通株式会社
Linuxソフトウェア事業部
五島康文 ( @YasunoriGoto1 )
0
2. Copyright 2019 FUJITSU LIMITED
五島康文
Linuxの開発部門で、OSS(Kernelやその周辺)の機能開発を担当
• エンタープライズ向け機能を開発
• OSSのコミュニティに、新機能などのパッチを投稿
• upstreamのソースに機能をマージするまでがmission
⇒ビジネスとしてupstreamへのマージが必須
• 2016/7~2019/1 不揮発メモリ(NVDIMM)を担当
Advent Calendar
• 技術者が技術記事をblogに書くのが年末の風物詩に
• Fujitsu Advent Calendarを最初にQiitaに作った人の一人 (2016/12)
• NVDIMMの記事を2016年より3年間Advent Calendarの1記事として記載
自己紹介
内容について講演依頼が来るように!
1
6. ソフトがNVDIMMを扱う際の注意点
不揮発になると、RAMと同じ扱いにはできない
突然の電源断などへの考慮が要
• 再起動前に書き込むことができたデータを確認し、再起動後に継続処理を行う必要
• そもそもCPU内部のcacheはまだ揮発性
NVDIMM上のデータに互換性が必要
• 不揮発メモリ内のデータについてMW/アプリ側で互換性を確保する必要
• ソフトのアップデートしても、NVDIMM内のデータ構造を変更してはならない
対故障性の確保が必要
• ソフトのバグやハード故障に対するデータの耐久性
• ハードウェアによるmirroringの仕組みが(少なくとも今のところ)なく、ソフト側で担保する必要
• データが破壊された場合、それをソフトとして検出および復旧できることが必要
領域管理とセキュリティ
• NVDIMM内の領域をどのように割り当てるか、割り当てた領域は正当な利用者か?
• 再起動前にNVDIMMの領域を使っていたプロセスと、再起動後のプロセスはホントに同じ?
Copyright 2019 FUJITSU LIMITED5
8. ストレージアクセスは無駄が多い
既存のI/Oの仕組みは、速度の遅いストレージのための設計
⇒NVDIMMには不要
Fileのメモリ上のキャッシュ(page cache) ⇒ NVDIMMでは無駄
デバイスドライバがI/O命令を発行 ⇒ NVDIMMではユーザプロセスが
read/writeを直接すればよいはず。ドライバ経由で書き込む処理が無駄
ブロックデバイスとしての管理が無駄 ⇒ page単位/ブロック単位にI/Oを溜
める/待ったり、I/Oの順序を変える処理も無駄
system call ⇒ ユーザーランドから書き込みできるのだから、user/kernel間
の切り替えの時間すら無駄
sync()/fsync()/msync()を呼ぶのも無駄
⇒ cpu cache flushでよいはず(前述の通り)
そもそも、せっかくCPUから直接触れるハードなんだから、NVDIMMをユーザ
プロセスのメモリ空間に直接マップすべき
Copyright 2019 FUJITSU LIMITED
NVDIMMのポテンシャルを引き出したいなら、
特徴を踏まえたうえで、新たなアクセス方法が必要
7
9. CPU cacheのflushすらも効率化が必要
CPU cache flushも効率的に行わないと遅い
x86の従来のCPUキャッシュのフラッシュには問題があった
• 実は同期型: clflush命令を実行すると、メモリに反映されるまで待つ ⇒ 遅い
• 内容をinvalidateしていた : flushしたキャッシュの内容は無効化される
• 同じデータにすぐにアクセスしたい場合でも、フラッシュ後はメモリからリロードする必要
⇒ この遅延すらも問題
(NVDIMMの性能がRAMよりも劣る場合、RAMより影響が大きい)
Intel CPUには現状の命令(clflush)に加え、新たに以下の二つが追加
• clflushopt : 非同期に複数のcache lineをflush可能
• clwb: さらにflushした内容をinvalidateせず、そのままcpu cacheに保持
• 非同期なので、いずれの命令もその後にメモリバリア(sfence)を行う必要がある
Copyright 2019 FUJITSU LIMITED
ソフトは
(上記の命令が使えるかどうかを判別した上で)
適切にCache のflushを行う必要
8
11. NVDIMMの3つのアクセス方法
NVDIMMの特徴を踏まえて、Linuxでは3つのアクセス方法を提供
1. 従来ストレージ(緑)
2. Filesystem DAX(青)
3. Device DAX(赤)
• もともとはSNIAの定義がベースになっている
NVDIMMの性能を最大限活かすには、2,または3を使う必要
いずれのインタフェース
も/dev経由でアクセス
管理コマンド(黄)も用意
アクセス方法の設定
ハードの状態取得
etc.
Copyright 2019 FUJITSU LIMITED
DAX 対応FS
NVDIMM
user 空間
kernel 空間
NVDIMMドライバpmem device daxドライバ
/dev/dax
NVDIMM専用アプリ
mmap()
BTT ドライバ
filesystem
従来アプリ NVDIMM 対応アプリ
ファイル
アクセス
ファイル
アクセス
& mmap()
PMDK
mdドライバ
管理コマンド
sysfs
ACPI driver
firmware
次ページから
それぞれについて説明
10
12. NVDIMMの3つのアクセス方法
NVDIMMの特徴を踏まえて、Linuxでは3つのアクセス方法を提供
1. 従来ストレージ(緑)
• NVDIMM上にFilesystemを構築して利用する (従来のソフトもそのまま使える)
• 従来のmdドライバなどにより、SoftRAIDなどの利用も可能
• NVDIMM本来の性能は引き出せない (HDDなど既存の低速なストレージ向けのI/Oの仕組み
を使うため)
• 従来のストレージハードウェアとの互換性を保つため、BTTドライバを用意
⇒ byte単位ではなく、HDD/SSDと同じようにブロック単位でデータ保存するための機構
Copyright 2019 FUJITSU LIMITED
NVDIMM
NVDIMMドライバpmem
BTT ドライバ
filesystem
従来アプリ
ファイル
アクセス
mdドライバ
11
13. NVDIMMの3つのアクセス方法
NVDIMMの特徴を踏まえて、Linuxでは3つのアクセス方法を提供
2. Filesystem DAX(青)
• 対応済みFilesystemでファイルをmmap()すると、ユーザプログラムからNVDIMMへ
直接アクセス可能
• 現在はext4, xfsが対応
• ファイルシステムのmount時に、-o daxオプションをつける必要
• read()/write()システムコールなどの一般的なファイルインタフェースも利用可能
• この際もpage cacheのような従来の遅いストレージ向けの処理はスキップ
• NVDIMM内の領域の管理や
アクセス権限のチェックなどは
Filesystemが行う
• 使いこなすためには
ソフトの改造が必要
• DAX経由でアクセスするため
のライブラリ・ツール群も提供
• PMDK(後述)
• kernelコミュ二ティでは
まだEXPERIMENTAL
(開発中)のstatus
Copyright 2019 FUJITSU LIMITED
DAX 対応FS
NVDIMM
user 空間
kernel 空間
NVDIMMドライバpmem
NVDIMM 対応アプリ
ファイル
アクセス
& mmap()
PMDK
12
14. NVDIMMの3つのアクセス方法
NVDIMMの特徴を踏まえて、Linuxでは3つのアクセス方法を提供
3. Device DAX(赤)
• /dev/dax を直接アプリ/MWがopen() + mmap() して利用
• 内部の領域管理などは原則、利用者責任
• ただし、後述のPMDKの高機能ライブラリを使えば、ライブラリ側で内部のpool管理も可能
• open()/mmap()/close()以外のシステムコールは利用不可
• read()/write()などもできない
• /dev/daxにはddコマンドも
利用不可
• PMDKはこちらもOK
• ddの代わりにPMDKは
daxioコマンドを用意
Copyright 2019 FUJITSU LIMITED
NVDIMM
user 空間
kernel 空間
device daxドライバ
/dev/dax
NVDIMM専用アプリ
mmap()PMDK
13
15. 3つのアクセス方法比較
比較
Copyright 2019 FUJITSU LIMITED
従来ストレージ Filesystem DAX Device DAX
用途例 従来のソフトをそのまま
利用
• 従来のソフトをNVDIMM向
けに改版
• 旧来のソフトとNVDIMM向
けソフトの共存
• 新ソフトの開発
NVDIMMにあわせた新型ソ
フトの開発
対応ファイルシ
ステム
サポートされているFS
全て
xfs, ext4 なし
データの保存
保障
sync(), fsync(),
msync()
• (後述) CPU cache flush のみで
OK
性能 ×:
OSの処理に無駄が多
いため3つの方式の中
ではもっとも遅い
△~○:
read()/write()でもpage cache
をスキップ
Fileをmmap()すればNVDIMM
を直接割り当てるため高速
◎:
OSの余計な処理が一切無
いため、最速
NVDIMMの領
域管理
FileSystemが管理 Filesystemが管理 kernel/driverは管理しない
(PMDKのpool管理を頼るか、
自前でやるか?)
冗長性の確保 mdドライバ/LVMなど
のしくみでmirroringは
可能
ハード・OSでは不可能。
アプリ・MWによる冗長性の確
保が必要
ハード・OSでは不可能。
アプリ・MWによる冗長性の
確保が必要
14
17. RAMと異なる概念が新たに2つ導入されている
NVDIMMを利用できるようにするには、この2つの設定を行う必要がある
1. region
• (CPUの中にある)メモリコントローラにより、NVDIMMの領域を区切る
• 複数のNVDIMMモジュールをまとめてinterleaveした領域にすることが可能
(注:DIMM3つでinterleaveすることは無い気もするが、概念図なのでご容赦)
• 基本的にはファームで設定する領域
NVDIMMの/devファイルへの見え方(1/2)
region 1
region 2
region 0
(This is
Interleaved
region)
System
Board
NVDIMM module1
NVDIMM module2
NVDIMM module 3
16
18. 2. namespace
• regionをnamespaceとして切り分けて、名前をつけて管理
• SCSIのLUNに相当すると説明される
• namespaceで名前(namespaceX.X)をつけると、それに対応するデバイスファイル
(/dev/pmemYYY or /dev/daxZZZ)も割り当てられる
• 1つのregionを複数のnamespaceに分けることも可能
• 従来ストレージのとき ⇒ /dev/pmem##s
• Filesystem DAXのとき ⇒ /dev/pmem##
• Device DAXのとき ⇒ /dev/dax##
NVDIMMの/devファイルへの見え方(2/2)
Copyright 2019 FUJITSU LIMITED
region 1
region 2
System
Board
NVDIMM module1
(nmem1)
NVDIMM module2
(nmem2)
NVDIMM module 3
(nmem3)
namespace0.0
/dev/pmem0
namespace1.0
/dev/pmem1s
namespace1.1
/dev/pmem1.1
namespac2.0
/dev/dax2
(region 0)
17
19. NVDIMMのLinuxの管理コマンド
ipmctl: regionの設定
Intel Optane DC Persistent memory 専用
regionの設定をファームの画面からではなく、Linuxのshellから実行できる
• 仕組み上、regionの設定後は再起動が必要
• https://github.com/intel/ipmctl
• (ファームの設定を行うツールなので、後述のエミュレーション環境ではおそらく動作不可)
ndctl : namespaceの設定・管理やDIMMの状態表示
Linux汎用で、Intel以外のHPEのNVDIMM-Nにも対応
• sysfsからACPIに問い合わせてファームとやり取り
• NVDIMMの状態表示、regionの表示やnamespaceの作成・管理ができる
• 3種類のアクセス方法の指定
• 従来ストレージ/ Filesystem DAX / Device DAX
⇒ 後述のnamespace設定時にオプションで指定
• 状態表示などの出力はJSONフォーマットで出力
• https://github.com/pmem/ndctl
Copyright 2019 FUJITSU LIMITED18
20. ndctl使い方例(1/2)
Filesystem DAXで利用する場合
Copyright 2019 FUJITSU LIMITED
$ sudo ndctl create-namespace -e "namespace0.0" -m fsdax -f
{
"dev":"namespace0.0",
"mode":"memory",
"size":"5.90 GiB (6.34 GB)",
"uuid":"dc47d0d7-7d8f-473e-9db4-1c2e473dbc8f",
"blockdev":"pmem0",
"numa_node":0
}
$ sudo parted /dev/pmem0
(parted) mklabel gpt
(parted) mkpart
パーティションの名前? []? nvdimm
ファイルシステムの種類? [ext2]? xfs
開始? 1M
終了? 6G
$ ls /dev/pmem*
/dev/pmem0 /dev/pmem0p1
namespaceの設定
-m fsdaxで
fsdaxで使うことを指定
-m fsdaxだと、
partitionは普通に
作成できる
19
21. ndctl使い方例(2/2)
Filesystem DAXの設定例
Copyright 2019 FUJITSU LIMITED
$ sudo mkfs.xfs /dev/pmem0p1
meta-data=/dev/pmem0p1 isize=512 agcount=4, agsize=386816
:
:
realtime =none extsz=4096 blocks=0, rtextents=0
$ sudo mount -o dax /dev/pmem0p1 /mnt/pmem
mkfsも通常と同様
(ただし、xfsの場合、-m reflink=1でreflink機能を有効にすると、
Filesystem DAXを有効にできない(2019年1月現在:後述)
mount時にoptionでFilesystem DAXとして使うことを指定
以後、/mnt/pmem配下のファイルをmmapすると
直接NVDIMMにアクセスできる
20
24. PMDK (1/3)
PMDK (Persistent Memory Development Kit)
https://github.com/pmem/pmdk
Filesystem DAX / Device DAXのためのライブラリ群
• libpmem : 低レイヤライブラリ(キャッシュのフラッシュ命令やsync()の実行)
• DAXのファイル・デバイスをmmapしたり、cpu cache flushなどのインタフェースを用意
• 前述のようなcpuのcache flushなどの機械語命令を直接呼び出すのは扱いづらい
⇒clflushopt, clwbが使える環境かどうかを、ライブラリ側で判定して適切に使ってくれる
• libpmemobj :トランザクションをサポートした高機能オブジェクトデータライブラリ
• データの保存時に逐一トランザクションを管理
• その他にも、libpmemlog, libpmemblkが、トランザクションをサポート
• ファイルにpoolを作って管理 ⇒ 利用にはpool名の指定が必要
• libpmemcto : 起動・終了時にのみNVDIMMにデータを保存、復旧
• libvmem : 不揮発メモリを広大な揮発メモリとして使うためのライブラリ
• libvmemmalloc: mallocを呼び出すと、RAMの代わりにNVDIMM側を揮発メモリと
して利用
• 環境変数LD_PRELOADの設定が必要
• librpmem: RDMAによるデータ転送のためのライブラリ (まだexperimental)
Copyright 2019 FUJITSU LIMITED23
25. PMDK(2/3)
ライブラリ以外のツール群も含まれる
pmempool
• Filesystem DAX上のファイルや、Device DAXの/dev/daxにpoolを作成・管理
• このpoolを使うのはlibpmemobj, libpmemblk, libpmemlog
daxio
• Device DAXではddコマンドが使えない(read(2) / write(2)できない)ため、その代替
その他
• pmreorder, pmdk-convert
実は、Windowsでも利用可能
https://github.com/pmem/pmdk/tree/master/src/windows
Copyright 2019 FUJITSU LIMITED24
26. PMDK(3/3)
現状
Intelとしてはlibpmemobjがとにかくイチオシ
libpmemctoは品質不十分で、結局depricatedに
巨大な揮発メモリとして使いたい場合、PMDKのlibvmemよりもlibmemkindの
利用を推奨するようになった
• http://memkind.github.io/memkind/
librpmemはexperimental
• Kernel側のDMA/RDMAの問題に起因すると思われる(後述)
Copyright 2019 FUJITSU LIMITED25
29. 仕様に記載されている既存のRAS機能
ACPIなどのファーム仕様で定義され、Linuxも対応済み
それぞれNVDIMMモジュールのSMART情報取得
• HDD/SSDの状態監視のようにNVDIMM用のSMARTを定義
• 以下のような情報が取得・出力・通知が可能
• NVDIMMのspare block の使用率 (SSDと同じく、故障したブロックのための予備がある)
• 温度監視 (素子 or コントローラなど)
• unsafe shutdown した回数(これを検出したらデータの復元機能をkickする想定か?)
Address Range Scrub
• そもそもMemoryというのは1bit errorが発生していてもそれに気づかない可能性
• 当該メモリにアクセスするまで1bit errorに気がつかない
• メモリアクセスは局所性があるので、しばらくアクセスせず放置されることがある
• さらに別のビットがerrorになると 2bit errorでエラー訂正不能に
• Scrub ⇒ メモリを一旦readして、1 bit errorがあれば訂正してデータを再書き込み
• ファームが実施(ソフトからもファームをkickできる)
• 実行中は、CPUパワーを使うと予想
error injectionも定義
• ハード故障時の動作をテストできる
Copyright 2019 FUJITSU LIMITED
では、これで十分だろうか?
28
33. NVDIMMの交換を難しくする要因(2/2)
Region/namespaceのため、交換手順がさらに煩雑に
以下の図のnamespace 0.0のどこかのblockが壊れた場合、ユーザは
NVDIMMを交換するために何をすればよいか?
Copyright 2019 FUJITSU LIMITEDCopyright 2018 FUJITSU LIMITEDCopyright 2018 FUJITSU LIMITED
region 1
region 2
System
Board
NVDIMM module1
(nmem1)
NVDIMM module2
(nmem2)
NVDIMM module 3
(nmem3)
namespace0.0
/dev/pmem0
namespace1.0
/dev/pmem1s
namespace1.1
/dev/pmem1.1
namespac2.0
/dev/dax2broken
(region 0)
32
34. Replacing broken NVDIMM (2/2)
NVDIMMを交換するためには以下の情報が必要
Copyright 2019 FUJITSU LIMITED
region 1
region 2
System
Board
NVDIMM module1
(nmem1)
NVDIMM module2
(nmem2)
NVDIMM module 3
(nmem3)
namespac0.0
/dev/pmem0
namespace1.0
/dev/pmem1s
namespace1.1
/dev/pmem1.1
namespac2.0
/dev/dax2broken
(region 0)
3. NVDIMMに含まれる
他のnamespaceの
判別が必要
(データをバックアップ
しないと、交換すると
こちらも消える)
1. どのNVDIMMモジュールが
壊れたのか判別できる必要
(特にinterleaveしている時は
判別できるのはファームだけ)
2. 交換・及びデータを退避するために
NVDIMMのモジュールの
マザーボード上の物理的な位置
(基板上のシルクプリントなど)と
/dev/xxxxの関係がわかる必要
33
36. Fujitsuで開発したRAS機能
NVDIMMのRASの問題点を緩和する機能の開発
ndctlに交換が必要なNVDIMMを判別するための機能を追加
1. NVDIMMモジュール (nmemX)のハードウェアID出力
⇒ SMBIOSのhandleなどを出力 ( dmidecodeコマンドでLocationを識別可能 )
2. 故障したブロックがどこのNVDIMMモジュールに所属するのかの情報を表示
⇒ Interleaveしている場合は、OSでは分からない
⇒ ACPI ver6.2の新仕様を使ってファームに問い合わせ
データが壊れる前に交換を促すため、NVDIMMの状態監視daemonを追加
• spareの利用率や温度などが閾値を超えたときに通知
⇒ ログの出力/他のプログラムをkick(予定)
• Intelとの議論で、以下のような通知のためのフレームワークとしても開発
• NVDIMMの設定変更の検出
• Address Range Scrubの完了通知
• unclean shutdown の検出など
詳しくは以下の資料参照
• https://www.slideshare.net/ygotokernel/the-ideal-and-reality-of-nvdimm-ras-
newer-version
Copyright 2019 FUJITSU LIMITED
いずれの機能もndctlにマージ済み
35
38. Filesystem DAXの課題とは
Filesystem DAXはまだ開発中(Experimental)のステータス
Upstream kernelでもFilesystem DAXをmountするとExperimental と表示
大きな要因
1. ストレージとメモリの両方の特徴を持つ
⇒今まで想定されていなかったコーナーケースが存在
(コーナーケースを知っていてそれを避けて使うなら、利用は可能)
2. 今年に入って実現したい機能が増えた (new!)
A) inodeごと(つまり、file や directoryごと)にDAXのon/offを切り替え
B) btrfsがまさかのFilesystem DAX対応に参戦
• FilesystemのCopy on Write(以後CoW)との両立が必須に!
Copyright 2019 FUJITSU LIMITED37
39. コーナーケースの問題と解決(1/2)
メタデータ更新タイミング
問題
• FileSystem DAX ではユーザアプリがCPU cacheのflushだけで
データは更新可能なはず…だった
⇒kernelがファイルシステムのメタデータを更新できるタイミングが無い
• ファイルの更新時間が反映されない
• truncate()によるデータブロックの削除を認識・調整するタイミングがない
• DMA/RDMAでNVDIMMにデータ転送中の領域をtruncate()で削除する可能性が!
メタデータ更新のための対策
• kernelに、mmap()の新 フラグMAP_SYNCの機能が追加された
• mmap()呼び出し時にこれを指定する
• kernrelはpage単位で書き込み禁止にして、データ更新時に必ずpage faultを発生
• page faultの延長で常にmetadataを更新
PMDKのインタフェースを使うと、内部でMAP_SYNCを指定
Copyright 2019 FUJITSU LIMITED
結局 fsync() とかを呼ばないといけないのでは…?
38
40. コーナーケースの問題と解決(2/2)
truncate()とDMA/RDMAの両立
今は暫定対処
• kernel/driver layerではDMA/RDMAによるデータ転送完了をtruncateが待つ
• user 空間に直接データ転送するドライバ(infinibandやvideo)は無限に待つ恐れ
⇒ そういうドライバは、DAXで使用中の領域にはデータ転送できないようにガードが入った
将来(推測込み)
• user空間に転送完了が終わったことを通知するcall backができる(かも?)
• ただし、以下のバグの解決のためのインタフェース確定が先
Copyright 2019 FUJITSU LIMITED
言い換えると、user空間へのDMA転送を
“使わない” と割りきってしまえば現状でもOK
• get_user_pages()を使って(R)DMA転送中の領域に対して、メモリ回収処理が誤った動作
⇒ 転送中の領域を示すためのインタフェースとしては不十分
• DMA/RDMA転送中の領域を”明示”するため以下のinterfaceの作成が検討中
• pin_user_pages() / unpin_user_pages()
そもそも user空間へのDMA/RDMA自体にrace condition bugが存在
39
41. inode単位のFS-DAX on/off切り替え
用途
以下のような用途を想定
状況
Linux Storage Filesystem & MM Summit(2019/5)で実装することに決定
実現するためには非常に多くの課題あり
Copyright 2019 FUJITSU LIMITED
• DAXをonにしたとき、それまでのpage cacheの扱いをどうするのか?
• page cacheのためのメソッドとDAX向けのメソッドの切り替え方法(排他の仕組みが必要)
• 今どのファイル/ディレクトリがDAXを使っているのかが判別できるインタフェース
• アプリ向けのon/off切り替えインタフェースはそもそも可能なのか?
• mount 時の-o daxオプションはそのうち無くなる? ⇒ 非互換発生?
指定する粒度を細かくしたい
(ファイルによって切り替えたい)
アプリ主導で on/off したい
page cache経由に切り替えたい
(write時の性能チューニング) 問題があったときの緊急回避
40
42. ファイルシステムのCoWとFilesystem DAX
1年前
もともとファイルシステムのCoWとFilesystem DAXは相性が良くなかった
• XFSのrelink/dedup機能とFilesystem DAXは排他の関係だった
• mkfs時のoptionで、reflink/dedupをonにすると、mount –o daxはreject
現在
btrfsもFilesystem DAXに対応する方向に
⇒ 上記と一緒に取り組む必要ができた
課題
• delayed allocation対策が必要 ⇒ 一時的にpage cacheに保存する(?)
• メモリ管理機構の対応が必要 ⇒ 後述
• iomapインタフェースの拡張が必要 ⇒ 後述
Copyright 2019 FUJITSU LIMITED
CoWはフラグメントしやすい特性
XFSはDelayed Allocationで対応
FS-DAXは
即座にblockを割り当てたい
41
43. ファイルシステムのCoWとメモリ管理機構
FilesystemのCoW (XFSではreflink/dedup機能)
• 異なるファイルでもデータの内容が同じブロックなら共有
• 共有されたブロックのデータ更新の際にCopy On Write
• あるfileのoffset 100のデータを違うfileのoffset 200のデータとして共有可能
• ファイルシステムの中だけで処理が完結
File System DAXにより
• DIMM故障時にメモリ管理機構側のリカバリ処理が必要に
• kernelの物理メモリ管理のデータ構造(struct page)は、同じpageに
「複数のファイルの異なるoffset」の情報を持つことを想定していない
• struct pageのほかのどこかに、複数offsetの情報を記録する必要ができた
• いまのところ、ここについてはまだ未開発
Copyright 2019 FUJITSU LIMITED
File A File B
offset 100 offset 200
42
44. ファイルシステムのCoWとiomap
Filesystem DAXではiomapという機構が利用されている
iomapのCoW対応インタフェース
• Write時にCopyするためのsource とtargetを指定
• データが重複していたしてたときのdedupをiomap でも対応
• etc.
• この開発には、南京富士通南大軟件技術有限公司も協力
btrfsのiomap対応も同時に開発中
Copyright 2019 FUJITSU LIMITED
旧来のblock層の構造体 buffer_head iomap
• I/Oのサイズは1 page 以内で、
512byteなどを想定
• NVDIMMには当然非効率
• 複数pageの処理を一度に実施可能
• まとめてpageをロックする機構を
Filesystem共通IFとして実現
• XFSは対応済み
• btrfsは非対応
• CoWのためのインタフェースが必要
43
46. まとめ、所感
Copyright 2019 FUJITSU LIMITED
Linuxの動向について概略を話した
NVDIMMの3つのアクセス方法
Region/namespace
PMDK
RAS
現在の課題
LinuxのNVDIMMのrealな実装が進んだ
storageとしての使い方やDevice DAXについては、ほぼ固まった印象
Filesystem DAXについては、現状が分かっている人なら利用可能
しかし、より良い機能・汎用的な機能にするための議論・開発が
活発に進められている
45
48. 関連規格
SNIA NVM Programming Model
NVDIMMのインタフェースについて概念的に定義
• https://www.snia.org/sites/default/files/technical_work/final/NVMProgramming
Model_v1.2.pdf
ファーム
ACPI https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
EFI
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Se
pt%206.pdf
• 共にNVDIMMのための仕様が追加されている
NVDIMM DSM Interface
• NVDIMMに対する固有のインタフェースを規定
• NVDIMMのSMART情報などの定義
• 各社、異なる定義をしている (HPEのNVDIMM-N向けの仕様など)
• Intel : http://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
namespace
NVDIMM Namespace Interface:
• http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
Copyright 2019 FUJITSU LIMITED47
49. NFIT (NVDIMM Firmware Interface Table)
OS起動時にNVDIMMの領域を認識するために必要なテーブル
以下が取得できる
• SPA(NVDIMMのシステム上の物理アドレス)
• region 情報
• interleave
• etc
かなり大きく、
複雑
• これを実装するの
はかなり大変
kernel sourceに
エミュレータが実装
• nfit_test.ko
• ndctlのテスト用
• 理解するにはこれを
読むほうが楽
(よく出来てる)
Copyright 2018 FUJITSU LIMITED48
51. display bad block information (1/2)
# ndctl list -DRHMu
{
"regions":[
{
"dev":"region0",
"size":"250.00 GiB (268.44 GB)",
:
"mappings":[
{
"dimm":"nmem1",
:
},
{
"dimm":"nmem0",
:
}
],
:
(cont)
Copyright 2018 FUJITSU LIMITED
region 0 is
interleaved region
by nmem1 and nmem0
command to show
region info with
dimm, health and bad block info
(output is JSON format)
50
52. display bad block information (2/2)
:
],
"badblock_count":1,
"badblocks":[
{
"offset":65536,
"length":1,
"dimms":[
"nmem0"
]
}
],
:
:
#
Copyright 2018 FUJITSU LIMITED
Current ndctl displays
which DIMM has badblock
in this region
In this example,
nmem0 has broken block
badblock info in the region
(the previous ndctl showed only
this information)
51
53. Example of SMBIOS Handle of ndctl
# ndctl list -Du
[
{
"dev":"nmem1",
"id":"XXXX-XX-XXXX-XXXXXXXX",
"handle":"0x120",
"phys_id":"0x1c"
},
{
"dev":"nmem0",
"id":"XXXX-XX-XXXX-XXXXXXXX",
"handle":"0x20",
"phys_id":"0x10",
"flag_failed_flush":true,
"flag_smart_event":true
}
]
Copyright 2018 FUJITSU LIMITED
display DIMM infomation
with human readable format
(phys_id becomes Hexadecimal)
phys_id is SMBIOS handle of
these DIMM
0x10 is broken DIMM’s handle
in this example
(The nmem0 included broken block
in previous result)
52
54. dmidecode can show the location of DIMM
# demidecode
:
Handle 0x0010, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0004
:
:
Locator: DIMM-Location-example-Slot-A
:
Type Detail: Non-Volatile Registered (Buffered)
Copyright 2018 FUJITSU LIMITED
SMBIOS handle of DIMM
Locator: shows the place of the DIMM
53
55. メモリのアクセス速度についての新仕様(1/2)
ACPI v6.2で新たに追加された仕様
• 個人的にちょっと注目
Memory Side Cache
• 遅いメモリに対してアクセス速度の速いメモリがcache
• 遅いメモリ側が不揮発なら、spec上は電源断時にプラットフォーム(ハード)で
データを保存する責任 ⇒ DIMM内でデータ保存する方向から変わってきた
HMAT :Heterogeneous
Memory Attribute Table
• メモリの具体的な
レイテンシやバンド幅の
値をファームから
OSに通知
• 従来のSLITは
最速からの相対値のみ
Copyright 2018 FUJITSU LIMITED54
56. メモリのアクセス速度についての新仕様(2/2)
HMATに対する動き
IntelはACPI v6.2の仕様公開(2017/5)と同時に、NVDIMM 開発コミュ二
ティにパッチ投稿して機能提案
• つまり、仕様公開にあわせて周到に準備していた可能性大
• ただ、あまり急ぐ理由がないのか、upstreamへのマージはのんびりペース
⇒とはいえ、さすがにそろそろ nvdimmのサブツリーに入りそうに見える
• sysfs経由でユーザ空間にこの値を提示しており、現在のところ、カーネル側では
この値は使っていない
⇒ 性能測定の参考とか、ワークロードの管理などを想定か?
Copyright 2018 FUJITSU LIMITED55
57. DMA/RDMAのPMDKのライブラリ
他のノードへの高速なデータの転送機能はやっぱり欲しい
データの配布・レプリケーションとして
クラウドでScale outしていくため
PMDKライブラリにはRDMAのためのライブラリも用意
librpmem(再掲)
• 他のnodeにデータをDMAで転送するための低レイヤライブラリ
• libfabricを利用しており、 RDMA転送が可能なRNIC利用が前提(?)
• 私もまだ動かせていません
• ステータスはExperimental
• 前述の通りKernel側の問題が残存のため(?)
• 昨年調べた段階では、接続のためにsshのkeyを各ノードへ設定が必要だった
⇒ 数が増えると設定が面倒かも (今後に期待か?)
• 低レイヤライブラリであるため、直接の利用は推奨されていない
• libpmemobjのような高機能ライブラリ経由を使うことが推奨されている模様
• pmempoolコマンド
• manによると、librpmemで設定したターゲットにレプリカも作れる模様
Copyright 2019 FUJITSU LIMITED56