Frontiers of Systems Programming

persistent memory

For decades there have been two clean categories: fast volatile memory (RAM) that the CPU reads and writes a byte at a time but loses the instant you cut power, and slow durable storage (disk, SSD) that survives a power loss but is read and written in big blocks through a long software path. Persistent memory is a class of hardware that blurs the line: it is byte-addressable like RAM - the CPU can load and store individual bytes with ordinary instructions - yet it is non-volatile, so its contents survive a power loss. Intel's Optane DC was the best-known example of this storage-class memory.

Concretely, you can map persistent memory into your address space and treat a data structure in it like ordinary memory: write a field with a normal store, read it back with a normal load, no read()/write() syscalls and no block I/O in between. The catch is durability ordering. A store reaches the CPU's caches first, and a sudden power loss can lose anything still sitting in cache. To make a write truly durable you must flush it out of the volatile caches to the persistent media and use a fence to order things - the flush-and-fence discipline. So a careful update is: write the new data, flush, fence, then flip a commit flag, flush, fence - so that on recovery you can tell finished updates from half-finished ones. Getting this ordering wrong gives you data that looks written but vanishes on a crash, or a structure left half-updated.

It matters because it promised a genuinely new programming model: durable data at memory speed and memory granularity, no serialization to blocks, with crash-consistent in-memory structures. But be honest about the present. The flagship product line (Optane) was discontinued, so the hardware's future is unsettled even as the ideas live on in research, in CXL-attached memory, and in battery-backed designs; and programming it correctly is genuinely hard - it demands the same careful ordering reasoning as lock-free code, plus crash-consistency thinking, which is why most software still treats durability as a storage concern rather than a memory one.

// durable update on persistent memory (flush-and-fence): p->value = 42; // ordinary store -- still only in cache flush(&p->value); fence(); // push it to persistent media, then order it p->committed = 1; // now mark it done flush(&p->committed); fence(); // make the commit flag durable too

A crash-consistent write to persistent memory: a plain store reaches only cache, so you flush it to the media and fence to order the data before the commit flag.

Byte-addressable does not mean automatically durable: a normal store lands in volatile CPU caches and is lost on power failure until you flush and fence it to the media. Note too that Optane, the flagship product, was discontinued - the ideas remain influential but the hardware story is genuinely unsettled.

Also called
non-volatile memoryNVMstorage-class memoryOptane非揮發性記憶體PMEM