SlideShare una empresa de Scribd logo
1 de 59
Descargar para leer sin conexión
Copyright 2019 FUJITSU LIMITED
不揮発メモリ(NVDIMM)と
Linuxの対応動向について
2019/3/20
富士通株式会社
Linux開発統括部
五島康文 ( @YasunoriGoto1 )
0
Copyright 2019 FUJITSU LIMITED
 五島康文
 Linuxの開発部門で、OSS(Kernelやその周辺)の機能開発を担当
• エンタープライズ向け機能を開発
• OSSのコミュニティに、新機能などのパッチを投稿し、upstreamのソース
に機能をマージするまでがmission
⇒ビジネスとしてupstreamへのマージが必須
• 2016/7~2019/1 不揮発メモリ(NVDIMM)を担当
 OSSの開発者を育てるのが個人的なライフワーク
• 社内でOSSコミュニティへの参加を推進
• プライベートでも若手を支援 ⇒ OSS Gateに参加
 Advent Calendar
• 元はクリスマスまでの日めくりカレンダー
• 技術者が技術記事をblogに書くのが年末の風物詩に
• Fujitsu Advent Calendarを最初にQiitaに作った人の一人 (2016/12)
• 裏話は懇親会で (すでにある程度は公開されてますが、さらにその背景まで)
• ほかの日本の大手会社も続いてくれて大変嬉しい
• NVDIMMの記事も2016年よりAdvent Calendarの1記事として記載
自己紹介
Cross 2017
今回の講演のきっかけ
1
本日の内容
 不揮発メモリ(NVDIMM)の特徴とLinuxの対応状況について概説
 技術的な内容を、基礎的な事から現在の状況までざっと紹介
 目次
 背景
 LinuxにおけるNVDIMMアクセス方法
 RegionとNamespace
 開発ライブラリ(ツール)
• PMDK
 NVDIMMのRAS
• Fujitsuで開発した機能の概略紹介
 Linux Kernelの現在の課題
 まとめ
Copyright 2019 FUJITSU LIMITED2
背景
Copyright 2019 FUJITSU LIMITED3
NVDIMMとは
 RAMのようにCPUから直接read/writeでき、かつ
システム停止・再起動後もデータが残る”不揮発のメモリ”
 従来のRAMのようなDIMM Slotに接続
 Non Volatile の DIMM ⇒ NVDIMM
• 今回はこのNVDIMMが対象
• NVMeなど、PCI expressなどに接続されるものについては今回は扱わない
 データ保存の確定方法
 今まで : RAMからディスク媒体まで書き出しが必要
 NVDIMMなら: 「理論上は」cpuのキャッシュフラッシュのみでOK!
 性能
 DIMM(RAM) と同程度か、若干遅い
 製品
 Intel Optane DC Persistent Memory (3D Xpointを使った最有力ハード)
 SAP HANA(On Memory DB):すでにマニュアルにNVDIMM対応を記載
Copyright 2019 FUJITSU LIMITED4
ソフトがNVDIMMを扱う際の注意点
 不揮発になると、RAMと同じ扱いにはできない
 突然の電源断などへの考慮が要
• 再起動前に書き込むことができたデータを確認し、再起動後に継続処理を行う必要
• そもそもCPU内部のcacheはまだ揮発性
 NVDIMM上のデータに互換性が必要
• 不揮発メモリ内のデータについてMW/アプリ側で互換性を確保する必要
• ソフトのアップデートしても、NVDIMM内のデータ構造を変更してはならない
 対故障性の確保が必要
• ソフトのバグやハード故障に対するデータの耐久性
• ハードウェアによるmirroringの仕組みが(少なくとも今のところ)なく、ソフト側で担保する必要
• データが破壊された場合、それをソフトとして検出および復旧できることが必要
 領域管理とセキュリティ
• NVDIMM内の領域をどのように割り当てるか、割り当てた領域は正当な利用者か?
• 再起動前にNVDIMMの領域を使っていたプロセスと、再起動後のプロセスはホントに同じ?
Copyright 2019 FUJITSU LIMITED5
NVDIMMをストレージとして使うと楽
 データを蓄積してきたストレージの技術は無視できない
 突然の電源断などへの考慮
⇒FilesystemのjournaringやCopy On Writeなどのしくみで、ある程度対処
(少なくとも、ファイルシステムとしての整合性は担保)
 互換性
⇒Filesystem のフォーマットで互換性確保済み
 対故障性の確保
⇒fsckやcheck sumなどfilesystem自身である程度対応をしている
 領域管理とセキュリティ
⇒Filesystemの権限チェックやSE Linuxなどの仕組みがすでに整っている
Copyright 2019 FUJITSU LIMITED
NVDIMMを簡単に使いたいなら、
Storageとして使う方法が一番簡単
6
ストレージアクセスは無駄が多い
 既存の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
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
LinuxのNVDIMMアクセス方法
Copyright 2019 FUJITSU LIMITED9
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
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
NVDIMMの3つのアクセス方法
 NVDIMMの特徴を踏まえて、Linuxでは3つのアクセス方法を提供
2. Filesystem DAX(青)
• 対応済みFilesystemでファイルをmmap()すると、ユーザプログラムからNVDIMMへ
直接アクセス可能
• 現在はext4, xfsが対応
• ファイルシステムのmount時に、-o daxオプションをつける必要
• read()/write()システムコールなどの一般的なファイルインタフェースも利用可能
• この際もpage cacheのような従来の遅いストレージ向けの処理はスキップ
• NVDIMM内の領域の管理や
アクセス権限のチェックなどは
Filesystemが行う
• 使いこなすためには
ソフトの改造が必要
• DAX経由でアクセスするため
のライブラリ・ツール群も提供
• PMDK(後述)
• kenrelコミュ二ティでは
まだEXPERIMENTAL
(開発中)のstatus
Copyright 2019 FUJITSU LIMITED
DAX 対応FS
NVDIMM
user 空間
kernel 空間
NVDIMMドライバpmem
NVDIMM 対応アプリ
ファイル
アクセス
& mmap()
PMDK
12
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
3つのアクセス方法比較
 比較
Copyright 2019 FUJITSU LIMITED
従来ストレージ Filesystem DAX Device DAX
用途例 従来のソフトをそのまま
利用
• 従来のソフトを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
RegionとNamespace
Copyright 2019 FUJITSU LIMITED15
 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
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
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
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
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
NVDIMMのエミュレーション
 RAMの一部をNVDIMMとして扱うエミュレーション
 RAMしかないマシンでも、NVDIMMのインタフェースを試すことが可能
• RAMの一部をNVDIMMのnamespace としてndctlで定義できる
• 前述の、mkfsやmount –o daxは同じように実行できる
 kernelのboot optionを指定
• memmap = XXG!YYG
• 物理アドレスYYGbyteのアドレスを先頭にXXGbyteのRAM領域をNVDIMMとして扱える
• カーネル起動時に、ファームから教えてもらうメモリマップのテーブル(e820)をカスタム
 後述のPMDKのインタフェースを試してみるというレベルなら、これでも十分
• お手軽なお試し環境としてお勧め
Copyright 2019 FUJITSU LIMITED21
開発ライブラリ(ツール)
Copyright 2019 FUJITSU LIMITED22
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によるデータ転送のためのライブラリ
Copyright 2019 FUJITSU LIMITED23
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
PMDK(3/3)
 現状
 Intelとしてはlibpmemobjがとにかくイチオシ
 libpmemctoは品質不十分で、結局depricatedに
 巨大な揮発メモリとして使いたい場合、PMDKのlibvmemよりもlibmemkindの
利用を推奨するようになった
• http://memkind.github.io/memkind/
 librpmemはexperimental
• Kernel側のDMA/RDMAの問題に起因すると思われる(後述)
Copyright 2019 FUJITSU LIMITED25
libpmemobjの使い方
 チュートリアルが記載されているので、詳しくはそちらを参照
 http://pmem.io/pmdk/libpmemobj/
 ライフサイクルの
状態遷移に応じた
コードを書く必要
 筆者は
触れていないが、
なかなか難しそう
な印象
Copyright 2019 FUJITSU LIMITED26
 RAS=Reliability Availability Serviceability
 Fujitsuが開発した機能の紹介
NVDIMMのRAS
Copyright 2019 FUJITSU LIMITED27
仕様に記載されている既存の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
NVDIMMのRASの問題点
 NVDIMMが壊れたら、壊れたものを交換できるか?
 まずは、以下の弊社サーバの写真から手順をイメージしてほしい
 HDD/SSDと比べて困ることは無いか?
Copyright 2019 FUJITSU LIMITED29
NVDIMMのRASの問題点
 NVDIMMは交換が難しい
 そもそも、以下のようにHDD/SSDのような仕組みがない
Copyright 2019 FUJITSU LIMITED
HDD/SSD
• スロットがあるので、ディスク単位を外から交換できる
• 機械の構造として、Hotplugが可能
NVDIMM
• RAMと同じく筐体の箱を開けないと交換できない
• Hotplugのための仕組みが無い
30
NVDIMMの交換を難しくする要因
 前述の通り、交換するためのハードの機能が無い
 mirroringの機能がない
 Filesystem DAX/ Device DAXでは、SoftRAIDによるmirrorもできない
• 仮に将来ハード的にmirrorが可能になったとしても、ペアは筐体内のNVDIMM
⇒ 結局システム停止させて筐体をあける必要
 交換の前にbackup が必須
⇒ データが壊れる前の予防保守が必要
 region/namespaceの存在が一層面倒に
 次項以降で説明
Copyright 2019 FUJITSU LIMITED31
NVDIMMの交換を難しくする要因(2/2)
 Region/namespaceのため、交換手順がさらに煩雑に
 以下の図でregion 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
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
予防保守のための機能
 せめて、完全に壊れてアクセスできなくなる前に交換したい
 mirrorも無いなら、壊れてからでは遅い
 NVDIMMのSMART情報にはSpare blockの使用率の情報もある
 ACPIの機能により、閾値より値が悪化したら、即座にユーザーランドへ通知
することもできる
Copyright 2019 FUJITSU LIMITED
NVDIMM will be broken !!!
Spare block ratio is low !!!
blocks spares
5%
ACPIの通知を拾って、カーネルレイヤーから
ユーザーランド「壊れそうだ」って教える存在(daemon)が必要
34
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
Linux kernelの現在の課題
Copyright 2019 FUJITSU LIMITED36
Filesystem DAXの課題
 Filesystem DAXはまだExperimentalのステータス
 Upstream kernelでもFilesystem DAXをmountするとExperimental と表示
 大きな要因
 ストレージとメモリの両方の特徴を持つ
⇒今まで想定されていなかったコーナーケースが存在
1. メタデータ更新
• FileSystem DAX ではCPU cache flushだけでユーザのデータは更新可能なはず
⇒しかし実際には、ファイルシステムのメタデータも更新も必要となる
⇒kerneがメタデータを更新できるタイミングが存在しない
• ファイルの更新時間が反映されない
• truncate()によるデータブロックの削除を認識・調整するタイミングがない
⇒ CPU cache flashだけでよいはずが、結局fsync()とか呼ばないといけないのでは?
• DMA/RDMAでNVDIMMに直接データ転送中の領域をtruncate()で削除してしまう可能性
2. XFSのreflink/dedup機能との両立
• 今は排他の関係 (無理に両立させる必要も無い)
• しかし、コミュニティでは両立させたいという意見が主流
Copyright 2019 FUJITSU LIMITED37
課題解決に向けた動き (1/3)
 解決した問題
 mmapの新 フラグMAP_SYNC
• mmap()をするときに新規のフラグであるMAP_SYNCを指定する
• page単位で書き込み禁止にして、データ更新時に必ずpage faultを発生させる
• page faultの延長で常にmetadataを更新
• PMDKのmmapインタフェースを使うと、中でMAP_SYNCを指定
 暫定的な対処がされた問題
 truncate()とDMA/RDMAの両立
• 現在のupstream
• kernel/driver layerではDMA/RDMAによるデータ転送完了をtruncateが待つようにした
• user 空間に直接データ転送するドライバ(infinibandやvideo)は無限に待ってしまう恐れ
⇒ そういうドライバは、DAXで使用中の領域には転送できないように修正
• 将来(推測込み)
• ユーザプロセス向けのcall backができる(かも?)
• とはいえ、そもそもfileをmmapしている領域へのRDMA自体にバグがあり、その修正が先
https://linuxplumbersconf.org/event/2/contributions/126/attachments/136/168/LPC_2
018_gup_dma.pdf
Copyright 2019 FUJITSU LIMITED38
課題解決に向けた動き (2/3)
 まだ今後の解決が必要な問題
 XFSのReflink/dedup機能とFilesystem DAXの両立 (内容は推測込み)
• Reflink/dedupは異なるファイルでもデータの内容が同じブロックなら共有
• 共有されたブロックのデータ更新の際はCopy On Write
• あるファイルのオフセット100のデータを違うファイルのオフセット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
39
課題解決に向けた動き (3/3)
 まだこれからの問題
 XFSのReflink/dedup機能との両立
• ReflinkのCOWに対しての対処が必要
• フラグメントを防ぐため、Delayed allocationの機能を利用
• 一方、Filesystem DAXは即座に領域を確保する機能⇒両立させるにはまだ工夫が必要
• COWでは一時的にRAMにデータを配置し、Delayed AllocationやMAP_SYNCでの書き
込み時にデータをNVDIMMに移すような処理が必要か?
(Dave Chinner の主張、“MAP_SYNC is guarantee, MAP_DIRECT is hint”)
 その他の細かい話
• ファイルシステム全体ではなく、inode単位でDAXにできないか?
• XFSで実装しかけたが、未解決 (具体的なユースケースがあれば進むかも?)
• DAX可能かをユーザプロセスから簡単に見分けられる方法が欲しくなる
• ndctlでFS-DAXのモードにしているのに、mount時の-o daxオプション必要?
• DAX可能なデバイスなら、mount無しでもデフォルトでDAXを有効にしたら?
• じゃあ、強制的にDAX disableにするオプション作る?
• etc.
Copyright 2019 FUJITSU LIMITED
完成度を高めていく努力がされている
40
DMA/RDMA
 他のノードへの高速なデータの転送機能はやっぱり欲しい
 データの配布・レプリケーションとして
 クラウドでScale outしていくため
 PMDKライブラリにはRDMAのためのライブラリも用意
 librpmem(再掲)
• 他のnodeにデータをDMAで転送するための低レイヤライブラリ
• libfabricを利用しており、 RDMA転送が可能なRNIC利用が前提(?)
• 私もまだ動かせていません
• ステータスはExperimental
• 前述の通りKernel側の問題が残存のため(?)
• 昨年調べた段階では、接続のためにsshのkeyを各ノードへ設定が必要だった
⇒ 数が増えると設定が面倒かも (今後に期待か?)
• 低レイヤライブラリであるため、直接の利用は推奨されていない
• libpmemobjのような高機能ライブラリ経由を使うことが推奨されている模様
• pmempoolコマンド
• manによると、librpmemで設定したターゲットにレプリカも作れる模様
Copyright 2019 FUJITSU LIMITED41
まとめ
Copyright 2019 FUJITSU LIMITED42
まとめ、所感
Copyright 2019 FUJITSU LIMITED
 Linuxの動向について概略を話した
 NVDIMMの3つのアクセス方法
 Region/namespace
 PMDK
 RAS
 現在の課題
 LinuxのNVDIMMのrealな実装が進んだ
 具体的で細かい題が見えている
⇒ そこまで開発が進んできた証
43
Copyright 2019 FUJITSU LIMITED44
関連規格
 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 LIMITED45
NFIT (NVDIMM Firmware Interface Table)
 OS起動時にNVDIMMの領域を認識するために必要なテーブル
 以下が取得できる
• SPA(NVDIMMのシステム上の物理アドレス)
• region 情報
• interleave
• etc
 かなり大きく、
複雑
• これを実装するの
はかなり大変
 kernel sourceに
エミュレータが実装
• nfit_test.ko
• ndctlのテスト用
• 理解するにはこれを
読むほうが楽
(よく出来てる)
Copyright 2018 FUJITSU LIMITED46
 筆者もあまり使ってないので、参考程度
PMDKを使ったプログラム
Copyright 2019 FUJITSU LIMITED47
libpmemの使用サンプル(open/mmap)
#include <libpmem.h>
#define PMEM_LEN 4096
int main(int argc, char *argv[])
{
int fd;
char *pmemaddr;
int is_pmem;
/* create a pmem file */
if ((fd = open("/pmem-fs/myfile", O_CREAT|O_RDWR, 0666)) < 0) {
perror("open");
exit(1);
}
/* allocate the pmem */
if ((errno = posix_fallocate(fd, 0, PMEM_LEN)) != 0) {
perror("posix_fallocate");
exit(1);
}
/* memory map it */
if ((pmemaddr = pmem_map(fd)) == NULL) {
perror("pmem_map");
exit(1);
}
/* pmemaddrに読み書き */
close(fd);
}
Copyright 2019 FUJITSU LIMITED48
libpmemの使用サンプル(cpu cache flush)
:
/* determine if range is true pmem */
is_pmem = pmem_is_pmem(pmemaddr, PMEM_LEN);
/* store a string to the persistent memory */
strcpy(pmemaddr, "hello, persistent memory");
/* flush above strcpy to persistence */
if (is_pmem)
pmem_persist(pmemaddr, PMEM_LEN);
else
pmem_msync(pmemaddr, PMEM_LEN);
Copyright 2019 FUJITSU LIMITED49
libpmemobjの使用例 (create/open)
int main(int argc, char *argv[])
{
const char path[] = "/pmem-fs/myfile";
PMEMobjpool *pop;
/* create the pmemobj pool or open it if it already exists */
pop = pmemobj_create(path, LAYOUT_NAME, POOL_SIZE, 0666);
if (pop == NULL)
pop = pmemobj_open(path, LAYOUT_NAME);
if (pop == NULL) {
perror(path);
exit(1);
}
/* ... */
pmemobj_close(pop);
}
Copyright 2019 FUJITSU LIMITED50
libpmemobjの使用例(objectの操作)
/* リストのへのアクセス例 */
struct listbase {
POBJ_LIST_HEAD(foo, struct foo_el) foo_list;
POBJ_LIST_HEAD(bar, struct bar_el) bar_list;
};
static void
list_insert(PMEMobjpool *pop, struct listbase *base, enum list_type type, int value)
{
struct list_constr_args args = {type, value};
switch (type) {
case LIST_FOO:
POBJ_LIST_INSERT_NEW_HEAD(pop, &base->foo_list, entries,
sizeof(struct foo_el), list_element_constr, &args);
break;
case LIST_BAR:
POBJ_LIST_INSERT_NEW_HEAD(pop, &base->bar_list, entries,
sizeof(struct bar_el), list_element_constr, &args);
break;
default:
assert(0);
}
}
Copyright 2019 FUJITSU LIMITED51
ndctl出力例
Copyright 2019 FUJITSU LIMITED52
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)
53
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)
54
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)
55
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
56
メモリのアクセス速度についての新仕様(1/2)
 ACPI v6.2で新たに追加された仕様
• 個人的にちょっと注目
 Memory Side Cache
• 遅いメモリに対してアクセス速度の速いメモリがcache
• 遅いメモリ側が不揮発なら、spec上は電源断時にプラットフォーム(ハード)で
データを保存する責任 ⇒ DIMM内でデータ保存する方向から変わってきた
 HMAT :Heterogeneous
Memory Attribute Table
• メモリの具体的な
レイテンシやバンド幅の
値をファームから
OSに通知
• 従来のSLITは
最速からの相対値のみ
Copyright 2018 FUJITSU LIMITED57
メモリのアクセス速度についての新仕様(2/2)
 HMATに対する動き
 IntelはACPI v6.2の仕様公開(2017/5)と同時に、NVDIMM 開発コミュ二
ティにパッチ投稿して機能提案
• つまり、仕様公開にあわせて周到に準備していた可能性大
• ただ、あまり急ぐ理由がないのか、upstreamへのマージはのんびりペース
⇒とはいえ、さすがにそろそろ nvdimmのサブツリーに入りそうに見える
• sysfs経由でユーザ空間にこの値を提示しており、現在のところ、カーネル側では
この値は使っていない
⇒ 性能測定の参考とか、ワークロードの管理などを想定か?
Copyright 2018 FUJITSU LIMITED58

Más contenido relacionado

La actualidad más candente

The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...
The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...
The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...Yasunori Goto
 
Ethernetの受信処理
Ethernetの受信処理Ethernetの受信処理
Ethernetの受信処理Takuya ASADA
 
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説Takateru Yamagishi
 
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
コンテナを止めるな!  PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとはコンテナを止めるな!  PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとはksk_ha
 
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介IBM Analytics Japan
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Kohei Tokunaga
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」Masahito Zembutsu
 
ARM CPUにおけるSIMDを用いた高速計算入門
ARM CPUにおけるSIMDを用いた高速計算入門ARM CPUにおけるSIMDを用いた高速計算入門
ARM CPUにおけるSIMDを用いた高速計算入門Fixstars Corporation
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Masahito Zembutsu
 
The Forefront of the Development for NVDIMM on Linux Kernel
The Forefront of the Development for NVDIMM on Linux KernelThe Forefront of the Development for NVDIMM on Linux Kernel
The Forefront of the Development for NVDIMM on Linux KernelYasunori Goto
 
GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...
GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...
GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...NTT DATA Technology & Innovation
 
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)NTT DATA Technology & Innovation
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...NTT DATA Technology & Innovation
 
Hopper アーキテクチャで、変わること、変わらないこと
Hopper アーキテクチャで、変わること、変わらないことHopper アーキテクチャで、変わること、変わらないこと
Hopper アーキテクチャで、変わること、変わらないことNVIDIA Japan
 
Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説貴仁 大和屋
 
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームApache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームKouhei Sutou
 

La actualidad más candente (20)

The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...
The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...
The Forefront of the Development for NVDIMM on Linux Kernel (Linux Plumbers c...
 
Ethernetの受信処理
Ethernetの受信処理Ethernetの受信処理
Ethernetの受信処理
 
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
 
OpenStack入門 2016/06/27
OpenStack入門 2016/06/27OpenStack入門 2016/06/27
OpenStack入門 2016/06/27
 
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
コンテナを止めるな!  PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとはコンテナを止めるな!  PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
 
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
Gstreamer Basics
Gstreamer BasicsGstreamer Basics
Gstreamer Basics
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
ARM CPUにおけるSIMDを用いた高速計算入門
ARM CPUにおけるSIMDを用いた高速計算入門ARM CPUにおけるSIMDを用いた高速計算入門
ARM CPUにおけるSIMDを用いた高速計算入門
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
perfを使ったPostgreSQLの解析(前編)
perfを使ったPostgreSQLの解析(前編)perfを使ったPostgreSQLの解析(前編)
perfを使ったPostgreSQLの解析(前編)
 
The Forefront of the Development for NVDIMM on Linux Kernel
The Forefront of the Development for NVDIMM on Linux KernelThe Forefront of the Development for NVDIMM on Linux Kernel
The Forefront of the Development for NVDIMM on Linux Kernel
 
GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...
GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...
GraalVMの多言語実行機能が凄そうだったので試しにApache Sparkに組み込んで動かしてみたけどちょっとまだ早かったかもしれない(Open So...
 
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
 
Hopper アーキテクチャで、変わること、変わらないこと
Hopper アーキテクチャで、変わること、変わらないことHopper アーキテクチャで、変わること、変わらないこと
Hopper アーキテクチャで、変わること、変わらないこと
 
Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説Prometheus入門から運用まで徹底解説
Prometheus入門から運用まで徹底解説
 
Apache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォームApache Arrow - データ処理ツールの次世代プラットフォーム
Apache Arrow - データ処理ツールの次世代プラットフォーム
 

Similar a 不揮発メモリ(NVDIMM)とLinuxの対応動向について

次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーションNTT Software Innovation Center
 
クライアント部会成果報告2011/日本OSS推進フォーラム
クライアント部会成果報告2011/日本OSS推進フォーラムクライアント部会成果報告2011/日本OSS推進フォーラム
クライアント部会成果報告2011/日本OSS推進フォーラムnamioto
 
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用Daichi Ogawa
 
IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』
IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』
IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』株式会社クライム
 
USENIX NSDI17 Memory Disaggregation
USENIX NSDI17 Memory DisaggregationUSENIX NSDI17 Memory Disaggregation
USENIX NSDI17 Memory DisaggregationKuniyasu Suzaki
 
サーバーだけじゃない! Linux デスクトップを使い倒そう! その1
サーバーだけじゃない! Linux デスクトップを使い倒そう! その1サーバーだけじゃない! Linux デスクトップを使い倒そう! その1
サーバーだけじゃない! Linux デスクトップを使い倒そう! その1Fuminobu Takeyama
 
XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!
XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!
XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!Hiroaki Komine
 
localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話
localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話
localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話真治 米田
 
ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜
ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜
ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜Hideki Takase
 
OpenSolaris Printing Environment
OpenSolaris Printing EnvironmentOpenSolaris Printing Environment
OpenSolaris Printing EnvironmentNaruhiko Ogasawara
 
XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)
XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)
XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)tokuhy
 
DEXCS 2018 for OpenFOAM ,How to install
DEXCS 2018 for OpenFOAM ,How to installDEXCS 2018 for OpenFOAM ,How to install
DEXCS 2018 for OpenFOAM ,How to installhideaki Kominami
 
[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...
[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...
[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...Insight Technology, Inc.
 
自己紹介とC# Devkitについて.pptx
自己紹介とC# Devkitについて.pptx自己紹介とC# Devkitについて.pptx
自己紹介とC# Devkitについて.pptxhkharu0803
 

Similar a 不揮発メモリ(NVDIMM)とLinuxの対応動向について (20)

次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
 
WakameTech #3
WakameTech #3WakameTech #3
WakameTech #3
 
クライアント部会成果報告2011/日本OSS推進フォーラム
クライアント部会成果報告2011/日本OSS推進フォーラムクライアント部会成果報告2011/日本OSS推進フォーラム
クライアント部会成果報告2011/日本OSS推進フォーラム
 
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用
 
第24回「IBM STGエバンジェリスト座談会 2013年のインフラエンジニアの生き方」(2013/01/17 on しすなま!)
第24回「IBM STGエバンジェリスト座談会 2013年のインフラエンジニアの生き方」(2013/01/17 on しすなま!)第24回「IBM STGエバンジェリスト座談会 2013年のインフラエンジニアの生き方」(2013/01/17 on しすなま!)
第24回「IBM STGエバンジェリスト座談会 2013年のインフラエンジニアの生き方」(2013/01/17 on しすなま!)
 
IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』
IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』
IBMビジネスパートナー合同フェア2019 『Veeamで簡単にクラウドへのバックアップ、リス トアことはじめ』
 
USENIX NSDI17 Memory Disaggregation
USENIX NSDI17 Memory DisaggregationUSENIX NSDI17 Memory Disaggregation
USENIX NSDI17 Memory Disaggregation
 
サーバーだけじゃない! Linux デスクトップを使い倒そう! その1
サーバーだけじゃない! Linux デスクトップを使い倒そう! その1サーバーだけじゃない! Linux デスクトップを使い倒そう! その1
サーバーだけじゃない! Linux デスクトップを使い倒そう! その1
 
XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!
XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!
XPages の最新機能を、XPages Extension Library Japan の日本語サンプルで試そう!
 
Debian emdebian 20100817
Debian emdebian 20100817Debian emdebian 20100817
Debian emdebian 20100817
 
WiredTigerを詳しく説明
WiredTigerを詳しく説明WiredTigerを詳しく説明
WiredTigerを詳しく説明
 
DevConf.cz 2020参加報告
DevConf.cz 2020参加報告DevConf.cz 2020参加報告
DevConf.cz 2020参加報告
 
localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話
localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話
localstackによるAWS Lambdaの開発環境を、miniconda上でつくったら簡単便利だった話
 
ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜
ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜
ロボットシステムのつくりかた 〜Robot Operating Systemというアプローチ〜
 
OpenSolaris Printing Environment
OpenSolaris Printing EnvironmentOpenSolaris Printing Environment
OpenSolaris Printing Environment
 
私とOSSの25年
私とOSSの25年私とOSSの25年
私とOSSの25年
 
XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)
XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)
XenServerとZFSストレージでサーバ仮想化 - OSC2011 Tokyo/Spring 自宅SAN友の会(後半)
 
DEXCS 2018 for OpenFOAM ,How to install
DEXCS 2018 for OpenFOAM ,How to installDEXCS 2018 for OpenFOAM ,How to install
DEXCS 2018 for OpenFOAM ,How to install
 
[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...
[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...
[db tech showcase Tokyo 2017] D33: Deep Learningや、Analyticsのワークロードを加速するには-Ten...
 
自己紹介とC# Devkitについて.pptx
自己紹介とC# Devkitについて.pptx自己紹介とC# Devkitについて.pptx
自己紹介とC# Devkitについて.pptx
 

不揮発メモリ(NVDIMM)とLinuxの対応動向について

  • 1. Copyright 2019 FUJITSU LIMITED 不揮発メモリ(NVDIMM)と Linuxの対応動向について 2019/3/20 富士通株式会社 Linux開発統括部 五島康文 ( @YasunoriGoto1 ) 0
  • 2. Copyright 2019 FUJITSU LIMITED  五島康文  Linuxの開発部門で、OSS(Kernelやその周辺)の機能開発を担当 • エンタープライズ向け機能を開発 • OSSのコミュニティに、新機能などのパッチを投稿し、upstreamのソース に機能をマージするまでがmission ⇒ビジネスとしてupstreamへのマージが必須 • 2016/7~2019/1 不揮発メモリ(NVDIMM)を担当  OSSの開発者を育てるのが個人的なライフワーク • 社内でOSSコミュニティへの参加を推進 • プライベートでも若手を支援 ⇒ OSS Gateに参加  Advent Calendar • 元はクリスマスまでの日めくりカレンダー • 技術者が技術記事をblogに書くのが年末の風物詩に • Fujitsu Advent Calendarを最初にQiitaに作った人の一人 (2016/12) • 裏話は懇親会で (すでにある程度は公開されてますが、さらにその背景まで) • ほかの日本の大手会社も続いてくれて大変嬉しい • NVDIMMの記事も2016年よりAdvent Calendarの1記事として記載 自己紹介 Cross 2017 今回の講演のきっかけ 1
  • 3. 本日の内容  不揮発メモリ(NVDIMM)の特徴とLinuxの対応状況について概説  技術的な内容を、基礎的な事から現在の状況までざっと紹介  目次  背景  LinuxにおけるNVDIMMアクセス方法  RegionとNamespace  開発ライブラリ(ツール) • PMDK  NVDIMMのRAS • Fujitsuで開発した機能の概略紹介  Linux Kernelの現在の課題  まとめ Copyright 2019 FUJITSU LIMITED2
  • 5. NVDIMMとは  RAMのようにCPUから直接read/writeでき、かつ システム停止・再起動後もデータが残る”不揮発のメモリ”  従来のRAMのようなDIMM Slotに接続  Non Volatile の DIMM ⇒ NVDIMM • 今回はこのNVDIMMが対象 • NVMeなど、PCI expressなどに接続されるものについては今回は扱わない  データ保存の確定方法  今まで : RAMからディスク媒体まで書き出しが必要  NVDIMMなら: 「理論上は」cpuのキャッシュフラッシュのみでOK!  性能  DIMM(RAM) と同程度か、若干遅い  製品  Intel Optane DC Persistent Memory (3D Xpointを使った最有力ハード)  SAP HANA(On Memory DB):すでにマニュアルにNVDIMM対応を記載 Copyright 2019 FUJITSU LIMITED4
  • 6. ソフトがNVDIMMを扱う際の注意点  不揮発になると、RAMと同じ扱いにはできない  突然の電源断などへの考慮が要 • 再起動前に書き込むことができたデータを確認し、再起動後に継続処理を行う必要 • そもそもCPU内部のcacheはまだ揮発性  NVDIMM上のデータに互換性が必要 • 不揮発メモリ内のデータについてMW/アプリ側で互換性を確保する必要 • ソフトのアップデートしても、NVDIMM内のデータ構造を変更してはならない  対故障性の確保が必要 • ソフトのバグやハード故障に対するデータの耐久性 • ハードウェアによるmirroringの仕組みが(少なくとも今のところ)なく、ソフト側で担保する必要 • データが破壊された場合、それをソフトとして検出および復旧できることが必要  領域管理とセキュリティ • NVDIMM内の領域をどのように割り当てるか、割り当てた領域は正当な利用者か? • 再起動前にNVDIMMの領域を使っていたプロセスと、再起動後のプロセスはホントに同じ? Copyright 2019 FUJITSU LIMITED5
  • 7. NVDIMMをストレージとして使うと楽  データを蓄積してきたストレージの技術は無視できない  突然の電源断などへの考慮 ⇒FilesystemのjournaringやCopy On Writeなどのしくみで、ある程度対処 (少なくとも、ファイルシステムとしての整合性は担保)  互換性 ⇒Filesystem のフォーマットで互換性確保済み  対故障性の確保 ⇒fsckやcheck sumなどfilesystem自身である程度対応をしている  領域管理とセキュリティ ⇒Filesystemの権限チェックやSE Linuxなどの仕組みがすでに整っている Copyright 2019 FUJITSU LIMITED NVDIMMを簡単に使いたいなら、 Storageとして使う方法が一番簡単 6
  • 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(後述) • kenrelコミュ二ティでは まだ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にあわせた新型ソ フトの開発 対応ファイルシ ステム サポートされている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
  • 22. NVDIMMのエミュレーション  RAMの一部をNVDIMMとして扱うエミュレーション  RAMしかないマシンでも、NVDIMMのインタフェースを試すことが可能 • RAMの一部をNVDIMMのnamespace としてndctlで定義できる • 前述の、mkfsやmount –o daxは同じように実行できる  kernelのboot optionを指定 • memmap = XXG!YYG • 物理アドレスYYGbyteのアドレスを先頭にXXGbyteのRAM領域をNVDIMMとして扱える • カーネル起動時に、ファームから教えてもらうメモリマップのテーブル(e820)をカスタム  後述のPMDKのインタフェースを試してみるというレベルなら、これでも十分 • お手軽なお試し環境としてお勧め Copyright 2019 FUJITSU LIMITED21
  • 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によるデータ転送のためのライブラリ 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
  • 27. libpmemobjの使い方  チュートリアルが記載されているので、詳しくはそちらを参照  http://pmem.io/pmdk/libpmemobj/  ライフサイクルの 状態遷移に応じた コードを書く必要  筆者は 触れていないが、 なかなか難しそう な印象 Copyright 2019 FUJITSU LIMITED26
  • 28.  RAS=Reliability Availability Serviceability  Fujitsuが開発した機能の紹介 NVDIMMのRAS Copyright 2019 FUJITSU LIMITED27
  • 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
  • 31. NVDIMMのRASの問題点  NVDIMMは交換が難しい  そもそも、以下のようにHDD/SSDのような仕組みがない Copyright 2019 FUJITSU LIMITED HDD/SSD • スロットがあるので、ディスク単位を外から交換できる • 機械の構造として、Hotplugが可能 NVDIMM • RAMと同じく筐体の箱を開けないと交換できない • Hotplugのための仕組みが無い 30
  • 32. NVDIMMの交換を難しくする要因  前述の通り、交換するためのハードの機能が無い  mirroringの機能がない  Filesystem DAX/ Device DAXでは、SoftRAIDによるmirrorもできない • 仮に将来ハード的にmirrorが可能になったとしても、ペアは筐体内のNVDIMM ⇒ 結局システム停止させて筐体をあける必要  交換の前にbackup が必須 ⇒ データが壊れる前の予防保守が必要  region/namespaceの存在が一層面倒に  次項以降で説明 Copyright 2019 FUJITSU LIMITED31
  • 33. NVDIMMの交換を難しくする要因(2/2)  Region/namespaceのため、交換手順がさらに煩雑に  以下の図でregion 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
  • 35. 予防保守のための機能  せめて、完全に壊れてアクセスできなくなる前に交換したい  mirrorも無いなら、壊れてからでは遅い  NVDIMMのSMART情報にはSpare blockの使用率の情報もある  ACPIの機能により、閾値より値が悪化したら、即座にユーザーランドへ通知 することもできる Copyright 2019 FUJITSU LIMITED NVDIMM will be broken !!! Spare block ratio is low !!! blocks spares 5% ACPIの通知を拾って、カーネルレイヤーから ユーザーランド「壊れそうだ」って教える存在(daemon)が必要 34
  • 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. メタデータ更新 • FileSystem DAX ではCPU cache flushだけでユーザのデータは更新可能なはず ⇒しかし実際には、ファイルシステムのメタデータも更新も必要となる ⇒kerneがメタデータを更新できるタイミングが存在しない • ファイルの更新時間が反映されない • truncate()によるデータブロックの削除を認識・調整するタイミングがない ⇒ CPU cache flashだけでよいはずが、結局fsync()とか呼ばないといけないのでは? • DMA/RDMAでNVDIMMに直接データ転送中の領域をtruncate()で削除してしまう可能性 2. XFSのreflink/dedup機能との両立 • 今は排他の関係 (無理に両立させる必要も無い) • しかし、コミュニティでは両立させたいという意見が主流 Copyright 2019 FUJITSU LIMITED37
  • 39. 課題解決に向けた動き (1/3)  解決した問題  mmapの新 フラグMAP_SYNC • mmap()をするときに新規のフラグであるMAP_SYNCを指定する • page単位で書き込み禁止にして、データ更新時に必ずpage faultを発生させる • page faultの延長で常にmetadataを更新 • PMDKのmmapインタフェースを使うと、中でMAP_SYNCを指定  暫定的な対処がされた問題  truncate()とDMA/RDMAの両立 • 現在のupstream • kernel/driver layerではDMA/RDMAによるデータ転送完了をtruncateが待つようにした • user 空間に直接データ転送するドライバ(infinibandやvideo)は無限に待ってしまう恐れ ⇒ そういうドライバは、DAXで使用中の領域には転送できないように修正 • 将来(推測込み) • ユーザプロセス向けのcall backができる(かも?) • とはいえ、そもそもfileをmmapしている領域へのRDMA自体にバグがあり、その修正が先 https://linuxplumbersconf.org/event/2/contributions/126/attachments/136/168/LPC_2 018_gup_dma.pdf Copyright 2019 FUJITSU LIMITED38
  • 40. 課題解決に向けた動き (2/3)  まだ今後の解決が必要な問題  XFSのReflink/dedup機能とFilesystem DAXの両立 (内容は推測込み) • Reflink/dedupは異なるファイルでもデータの内容が同じブロックなら共有 • 共有されたブロックのデータ更新の際はCopy On Write • あるファイルのオフセット100のデータを違うファイルのオフセット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 39
  • 41. 課題解決に向けた動き (3/3)  まだこれからの問題  XFSのReflink/dedup機能との両立 • ReflinkのCOWに対しての対処が必要 • フラグメントを防ぐため、Delayed allocationの機能を利用 • 一方、Filesystem DAXは即座に領域を確保する機能⇒両立させるにはまだ工夫が必要 • COWでは一時的にRAMにデータを配置し、Delayed AllocationやMAP_SYNCでの書き 込み時にデータをNVDIMMに移すような処理が必要か? (Dave Chinner の主張、“MAP_SYNC is guarantee, MAP_DIRECT is hint”)  その他の細かい話 • ファイルシステム全体ではなく、inode単位でDAXにできないか? • XFSで実装しかけたが、未解決 (具体的なユースケースがあれば進むかも?) • DAX可能かをユーザプロセスから簡単に見分けられる方法が欲しくなる • ndctlでFS-DAXのモードにしているのに、mount時の-o daxオプション必要? • DAX可能なデバイスなら、mount無しでもデフォルトでDAXを有効にしたら? • じゃあ、強制的にDAX disableにするオプション作る? • etc. Copyright 2019 FUJITSU LIMITED 完成度を高めていく努力がされている 40
  • 42. DMA/RDMA  他のノードへの高速なデータの転送機能はやっぱり欲しい  データの配布・レプリケーションとして  クラウドでScale outしていくため  PMDKライブラリにはRDMAのためのライブラリも用意  librpmem(再掲) • 他のnodeにデータをDMAで転送するための低レイヤライブラリ • libfabricを利用しており、 RDMA転送が可能なRNIC利用が前提(?) • 私もまだ動かせていません • ステータスはExperimental • 前述の通りKernel側の問題が残存のため(?) • 昨年調べた段階では、接続のためにsshのkeyを各ノードへ設定が必要だった ⇒ 数が増えると設定が面倒かも (今後に期待か?) • 低レイヤライブラリであるため、直接の利用は推奨されていない • libpmemobjのような高機能ライブラリ経由を使うことが推奨されている模様 • pmempoolコマンド • manによると、librpmemで設定したターゲットにレプリカも作れる模様 Copyright 2019 FUJITSU LIMITED41
  • 44. まとめ、所感 Copyright 2019 FUJITSU LIMITED  Linuxの動向について概略を話した  NVDIMMの3つのアクセス方法  Region/namespace  PMDK  RAS  現在の課題  LinuxのNVDIMMのrealな実装が進んだ  具体的で細かい題が見えている ⇒ そこまで開発が進んできた証 43
  • 46. 関連規格  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 LIMITED45
  • 47. NFIT (NVDIMM Firmware Interface Table)  OS起動時にNVDIMMの領域を認識するために必要なテーブル  以下が取得できる • SPA(NVDIMMのシステム上の物理アドレス) • region 情報 • interleave • etc  かなり大きく、 複雑 • これを実装するの はかなり大変  kernel sourceに エミュレータが実装 • nfit_test.ko • ndctlのテスト用 • 理解するにはこれを 読むほうが楽 (よく出来てる) Copyright 2018 FUJITSU LIMITED46
  • 49. libpmemの使用サンプル(open/mmap) #include <libpmem.h> #define PMEM_LEN 4096 int main(int argc, char *argv[]) { int fd; char *pmemaddr; int is_pmem; /* create a pmem file */ if ((fd = open("/pmem-fs/myfile", O_CREAT|O_RDWR, 0666)) < 0) { perror("open"); exit(1); } /* allocate the pmem */ if ((errno = posix_fallocate(fd, 0, PMEM_LEN)) != 0) { perror("posix_fallocate"); exit(1); } /* memory map it */ if ((pmemaddr = pmem_map(fd)) == NULL) { perror("pmem_map"); exit(1); } /* pmemaddrに読み書き */ close(fd); } Copyright 2019 FUJITSU LIMITED48
  • 50. libpmemの使用サンプル(cpu cache flush) : /* determine if range is true pmem */ is_pmem = pmem_is_pmem(pmemaddr, PMEM_LEN); /* store a string to the persistent memory */ strcpy(pmemaddr, "hello, persistent memory"); /* flush above strcpy to persistence */ if (is_pmem) pmem_persist(pmemaddr, PMEM_LEN); else pmem_msync(pmemaddr, PMEM_LEN); Copyright 2019 FUJITSU LIMITED49
  • 51. libpmemobjの使用例 (create/open) int main(int argc, char *argv[]) { const char path[] = "/pmem-fs/myfile"; PMEMobjpool *pop; /* create the pmemobj pool or open it if it already exists */ pop = pmemobj_create(path, LAYOUT_NAME, POOL_SIZE, 0666); if (pop == NULL) pop = pmemobj_open(path, LAYOUT_NAME); if (pop == NULL) { perror(path); exit(1); } /* ... */ pmemobj_close(pop); } Copyright 2019 FUJITSU LIMITED50
  • 52. libpmemobjの使用例(objectの操作) /* リストのへのアクセス例 */ struct listbase { POBJ_LIST_HEAD(foo, struct foo_el) foo_list; POBJ_LIST_HEAD(bar, struct bar_el) bar_list; }; static void list_insert(PMEMobjpool *pop, struct listbase *base, enum list_type type, int value) { struct list_constr_args args = {type, value}; switch (type) { case LIST_FOO: POBJ_LIST_INSERT_NEW_HEAD(pop, &base->foo_list, entries, sizeof(struct foo_el), list_element_constr, &args); break; case LIST_BAR: POBJ_LIST_INSERT_NEW_HEAD(pop, &base->bar_list, entries, sizeof(struct bar_el), list_element_constr, &args); break; default: assert(0); } } Copyright 2019 FUJITSU LIMITED51
  • 54. 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) 53
  • 55. 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) 54
  • 56. 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) 55
  • 57. 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 56
  • 58. メモリのアクセス速度についての新仕様(1/2)  ACPI v6.2で新たに追加された仕様 • 個人的にちょっと注目  Memory Side Cache • 遅いメモリに対してアクセス速度の速いメモリがcache • 遅いメモリ側が不揮発なら、spec上は電源断時にプラットフォーム(ハード)で データを保存する責任 ⇒ DIMM内でデータ保存する方向から変わってきた  HMAT :Heterogeneous Memory Attribute Table • メモリの具体的な レイテンシやバンド幅の 値をファームから OSに通知 • 従来のSLITは 最速からの相対値のみ Copyright 2018 FUJITSU LIMITED57
  • 59. メモリのアクセス速度についての新仕様(2/2)  HMATに対する動き  IntelはACPI v6.2の仕様公開(2017/5)と同時に、NVDIMM 開発コミュ二 ティにパッチ投稿して機能提案 • つまり、仕様公開にあわせて周到に準備していた可能性大 • ただ、あまり急ぐ理由がないのか、upstreamへのマージはのんびりペース ⇒とはいえ、さすがにそろそろ nvdimmのサブツリーに入りそうに見える • sysfs経由でユーザ空間にこの値を提示しており、現在のところ、カーネル側では この値は使っていない ⇒ 性能測定の参考とか、ワークロードの管理などを想定か? Copyright 2018 FUJITSU LIMITED58