Abstract

Intel’s decision to discontinue Optane Persistent Memory in 2022 effectively ended the first commercial era of byte-addressable non-volatile memory on the CPU memory bus. But the programming models, software stacks, and architectural insights that Optane’s brief deployment produced are not going away. Several successor technologies, including Samsung’s CXL-attached DRAM-backed persistent modules and emerging FeRAM and MRAM prototypes from imec and CEA-Leti, are targeting the same programming interface. This post examines what the Optane deployment taught architects and systems programmers about PMEM programming models, where those lessons are being applied in the post-Optane landscape, and what hardware assumptions the software stack was forced to expose.

What Optane Exposed About Persistence Semantics

The central difficulty of byte-addressable persistent memory programming is persistence ordering: ensuring that stores to PMEM reach the media in a defined order so that crash recovery can reconstruct consistent state. x86 provided the CLWB (Cache Line Write Back) and CLFLUSHOPT instructions along with SFENCE to create ordered persistence points, but the semantics were subtle. A store followed by CLWB followed by SFENCE guaranteed persistence only if the memory controller’s write-pending queues were also flushed, which required the ADR (Asynchronous DRAM Refresh) domain to cover the controller. On Optane DIMM systems, Intel guaranteed the controller write queues were in the ADR domain; on systems without that hardware guarantee, software had to use PCOMMIT (later removed from the ISA as unnecessary on ADR-capable platforms). The PMDK library from Intel, now maintained by the Persistent Memory Development Kit community under Linux Foundation, encapsulated these semantics behind a transaction abstraction, but the abstraction leaked whenever applications needed to reason about flush granularity and ordering on hot paths.

CXL as the New PMEM Interface

With Optane gone, the most practical path to byte-addressable persistence in the near term runs through CXL 3.0’s Type 3 memory devices with battery-backed or capacitor-backed write buffers. Samsung and SK Hynix have both demonstrated CXL memory expansion modules with hardware persistence guarantees at the device level. The programming model shifts: instead of a CPU-side cache flush instruction persisting data through the memory controller, the application marks a CXL memory region as persistent via a capability flag in the CXL device enumeration, and the device guarantees that writes which reach its controller are persisted to backing media on power loss. This moves persistence from a CPU instruction sequence problem to a device capability negotiation problem. The SNIA NVM Programming Model specification and its CXL annex, updated through 2024, covers this interface for Linux’s DAX (Direct Access) path.

Software Stack Continuity

The good news is that most of the PMDK abstraction layer remains applicable. The libpmemobj transaction log format, the PMEM2 mapping API, and the pmempool recovery tools all abstract over the hardware persistence mechanism. Applications written to the PMDK API should be portable to CXL-backed persistent regions with a recompile against updated PMEM2 backends. The Linux kernel’s DAX code path, which exposes persistent memory regions as memory-mappable character devices via /dev/dax or as ext4-dax and XFS-dax mounts, has CXL device support merged as of kernel 6.x. The harder migration is for applications that directly used Optane-specific features like NUMA interleaving across DRAM and PMEM tiers via numactl, since CXL-attached devices appear on a different NUMA node with higher latency.

Outlook

The non-volatile memory research community has largely shifted attention to tiered memory management, where byte-addressable persistence is one property of a memory tier rather than a special-purpose device class. Projects like the Linux DAMON (Data Access MONitor) subsystem and the heterogeneous memory management work merged in kernel 6.5-6.8 provide the kernel infrastructure to migrate pages between tiers based on access frequency, a pattern that maps naturally onto future FeRAM or MRAM devices when they reach production densities.