不揮発性メモリと永続化 ─ PMEM・キャッシュフラッシュの順序保証

バイトアドレス可能な不揮発メモリとは

従来、不揮発な記憶はブロック単位のストレージ（SSD/HDD）で、CPUはI/Oパスとキューを通してブロックを読み書きしていました。これに対し**永続メモリ（PMEM, Persistent Memory）**は、DRAMと同じメモリバスにぶら下がり、バイト単位でCPUのロード／ストア命令から直接触れる不揮発媒体です。代表が DRAM とフラッシュを同居させた NVDIMM-N や、媒体自体が不揮発な NVDIMM-P、そして近年はメモリをCXLコヒーレント接続経由で拡張する CXL PMEM です。OSはこれを mmap でアドレス空間に直結（DAX, Direct Access）でき、ページキャッシュを介さずアプリが直接書き込めます。

ここに本質的な難所があります。store 命令を実行しても、その値が即座に不揮発媒体へ届くわけではない、という点です。

永続化ドメイン：何が停電を生き残るか

CPUがストアした値は、まずキャッシュ階層（L1/L2/LLC）やストアバッファ、メモリコントローラ内のバッファを順に通り、最後に媒体へ書かれます。途中の段はすべて揮発性です。電源が落ちた瞬間にどこまでが残るかを決めるのが**永続化ドメイン（persistence domain）**で、「ここに入ったデータは停電してもハードが必ず媒体へ書き切る」と保証される境界です。

Intelプラットフォームには2つの段階があります。

ADR（Asynchronous DRAM Refresh）は、メモリコントローラのWPQ（Write Pending Queue）までを永続化ドメインとします。停電を検知すると、電源装置の残留エネルギーでWPQ内の書き込みを媒体へ吐き切ります。ただしCPUキャッシュは含まれないため、キャッシュに留まったままのストアは失われます。だからソフトウェアが明示的にキャッシュ行をWPQへ追い出さなければなりません。

**eADR（enhanced ADR）**は、より大きな残留電力でCPUキャッシュまで永続化ドメインに含めます。これならアプリは明示フラッシュを省けますが、順序を保証するフェンスは依然として必要です。永続化ドメインの範囲と、操作間の順序保証は別問題だからです。

CLWB/CLFLUSHOPT＋SFENCEによる順序保証

ADR環境でキャッシュ行を永続化ドメインへ送り出す命令が、x86のキャッシュ行フラッシュ系です。それぞれ性質が異なります。

要点は2つあります。第一に、CLWBは行を無効化せずキャッシュに残したまま書き戻すので、永続化した直後にその領域を再び読み書きする典型パターンでミスを増やしません。第二に、CLFLUSHOPT/CLWBは弱順序で、互いに、また周囲のストアと並べ替わり得ます。複数行を続けて吐き出すとき並列に進めて速い反面、「フラッシュがいつ完了したか」は命令の発行だけでは分からないのです。

そこで完了を待つのがSFENCE（ストアフェンス）です。SFENCEは、それ以前に発行した CLWB/CLFLUSHOPT と通常ストアが、フェンスを越えて後続の操作より先に順序づけられることを保証します。永続化の最小手順はこうなります。

store  pmem[addr] = value     // ① 値を書く（まだキャッシュ内）
clwb   pmem[addr]             // ② その行を永続化ドメインへ書き戻し要求
sfence                        // ③ ①②の完了を待つ＝ここで初めて永続化が保証

SFENCEを省くと、clwb が裏で進行中のまま次の処理（特に後述のコミットフラグ更新）へ進んでしまい、停電時にコミット済みフラグだけが残ってデータが残らないという最悪の不整合を招きます。eADR環境では clwb は省けますが、操作の前後関係を作るフェンスは残すのが鉄則です。CLWB/CLFLUSHOPT 自体が弱順序であることは、メモリ一貫性モデルで扱う緩和の一種だと捉えると整理しやすいでしょう。

クラッシュ整合性と書き込み順序

永続メモリの真の難しさは、単一行の永続化ではなく、複数の永続化操作の途中で停電したときに現れます。停電は任意の瞬間に起こり得るので、どの順序で媒体へ反映されるかを制御しないと、回復不能な中間状態が残ります。

定番が、データ本体と「有効である」ことを示すコミットフラグを別々に書く構造です。順序を誤ると壊れます。

正しい順序：
  data を書く → clwb → sfence → committed=1 を書く → clwb → sfence

もし sfence を挟まず committed を先に永続化してしまうと：
  停電時、committed=1 だけが残り data は古いまま
  → 回復処理は『有効』と誤認し、壊れたデータを読む

つまり「依存する側（フラグ）は、依存される側（データ）が確実に永続化した後でのみ永続化する」という半順序を、フラッシュ＋フェンスで明示的に張る必要があります。これはstoreとフラグの公開順序と同型の問題が、可視性ではなく永続性の軸で現れたものです。

ログによるアトミックな更新

しかし1ワードのフラグで守れるのは、書き込みが1回のアトミックな更新で完結する場合に限られます。8バイトを超える更新や、複数箇所をまとめて「全部反映か全部未反映か」にしたい場合、フラグ方式では途中状態が露出します。ここで使うのが**トランザクション（ログ）**です。

• undoログ（取り消しログ）：書き換える前の旧値をログに記録・永続化してから、本体を上書きする。途中で停電したら回復時にログの旧値で巻き戻し、更新が「無かったこと」にする。
• redoログ（やり直しログ）：新値を先にログへ書いて永続化し、コミットマークを付けてから本体へ反映する。停電したらログを再生して更新を「やり切る」。本体反映前なら破棄する。

どちらも核心は同じで、ログの永続化と本体の更新の間に厳密なフェンス順序を置くことです。たとえばredoログなら次の順序を守ります。

redoログの手順：
  log にエントリ書く → clwb → sfence       // ① ログを先に永続化
  commit マークを書く → clwb → sfence       // ② コミット点（ここを越えれば成立）
  本体 data へ反映     → clwb → sfence       // ③ 本体へ適用
  ログを解放（チェックポイント）

①②の間で停電すれば未コミット＝破棄、②③の間なら回復時に再生、とコミットマークの永続化を分岐点にアトミック性が担保されます。PMDK（Persistent Memory Development Kit）の libpmemobj などはこのログ管理とフラッシュ順序を内部で行い、アプリは「トランザクション内の更新」を書くだけで済むよう抽象化しています。媒体そのものの不揮発化の物理は新型不揮発メモリの物理が、ブロックストレージ側の整合性手法はstorage-io-path-queuesと合わせて読むと対比が効きます。

まとめ

• PMEM（NVDIMM/CXL PMEM）はバイト単位でロード／ストアから触れる不揮発媒体だが、ストアした値はまずキャッシュに留まり、停電を生き残るのは永続化ドメイン到達済みのデータだけ。
• 永続化ドメインの範囲はADR（WPQまで）かeADR（CPUキャッシュまで）かで決まり、ADRではソフトが明示的にキャッシュ行をフラッシュする。
• 永続化はCLWB（行を残す）/CLFLUSHOPT（弱順序）でフラッシュ要求し、SFENCEで完了と順序を保証する。フラッシュとフェンスは対で使う。
• クラッシュ整合性はデータ→フラッシュ→フェンス→コミットフラグの順序が要で、8バイトを超えるアトミック更新はundo/redoログのトランザクションで担保する。