In this post The SSD Guy will discuss the SNIA Nonvolatile Memory (NVM) Programming Model, a framework to allow standard applications to take advantage of nonvolatile, or persistent, memory in any system that includes persistent memory,
This model is enormously important to the future of computing, yet few people even know that it exists. It’s a fundamental change to the way that application programs access storage that will have significant ramifications to computer architecture and performance over the long term.
Here’s why: The industry is moving towards larger-scale systems that mix persistent memory with standard DRAM into a single memory address space. Persistent memory has an advantage over volatile DRAM, since it maintains data after power is removed or lost. Because of this certain application programs will want to know which memory is volatile and which is persistent and to take advantage of whatever persistent memory the system might provide. I say “Larger-Scale” systems because small systems often combine NOR flash and SRAM in the same memory space. The difference with these smaller systems is that they are almost always based on custom firmware that is specifically programmed to understand which memory is volatile (the SRAM) and which is not (the flash.) Larger-scale systems typically use off-the-shelf software that does not automatically understand the unique hardware characteristics of each system in which it is used. This is one of the most important benefits of using an operating system: The operating system manages the hardware in such a way that the application program doesn’t need to be changed to work on a wide range of very different hardware.
Intel’s new Optane DIMM (officially known as the Intel Optane DC Persistent Memory) is one example of a persistent memory that can be added into the memory address space alongside of the system’s DRAM, but it’s not the first. The path for the Optane DIMM has been previously paved with the NVDIMM-N module available from companies like Cypress/AgigA, Viking, Netlist, and Micron, or the MRAM DIMM that Everspin has demonstrated.
The SNIA NVM Programming Model allows applications to ask the operating system how much persistent memory the system has (if any), and then to tell the operating system to write certain data to the persistent memory and other data to standard memory (DRAM). All this is done without the application having to know exactly where that persistent memory actually resides within the memory address space.
The NVM Programming Model gives guidelines for how an operating system handles persistent memory, but it is not actually the program itself, nor even a formal specification. It’s the operating system that actually provides this information to the application. The NVM Programming Model is an “interface”, not a concrete API (Application Programming Interface), and it is not literally running on any system. Instead, it specifies the architecture and semantics of a persistent memory programming interface. Libraries and operating systems implement their own APIs, which applications actually call.
The basic functioning of the model is described in the diagram below:
This is very similar to a diagram for a system that doesn’t include persistent memory. In past operating systems the application program (yellow, top) interacted with storage through the file system (gray, upper middle) which communicated through various drivers (green, lower middle) with (persistent) storage devices which would appear at the bottom in other diagrams. The application program would also communicate with memory through the MMU mappings which were managed by the file system (far right). Everything is managed by the kernel.
Data that needed to survive a power failure was carefully written to storage while data that was less critical could be maintained in memory, which was always volatile.
Persistent memory blurs the difference between memory and storage, since storage is persistent and memory is typically not. Future systems will be able to use persistent memory to store much of the critical data that formerly was written into an SSD or HDD. Since memory is thousands of times faster than SSD storage, and millions of times as fast as an HDD, this will result in significantly faster computing, even if processors themselves don’t improve.
But yesterday’s operating systems don’t manage memory as storage, so this is where the SNIA model becomes necessary. How do applications programs take advantage of the persistent memory in a system if they don’t always know where it is? This problem is automatically solved if the operating system manages persistent and volatile memory according to the SNIA NVM Programming Model. The NVM Programming Model supports new operating system calls to allow an application program to request a block of persistent memory that it can read and write like memory, and to also access persistent memory as it would an SSD or an HDD. The first of these is indicated by the dashed vertical line at the far right, and the second is performed through more conventional operations using the “Native File API” vertical line. The wavy red lines represent the focus areas for development: the NVM.PM.File Mode and the NVM.PM.Volume Mode.
Standard operating systems already support the NVM programming Model. Microsoft has built “DAX” (Direct Access mode) into its NT File System for operating systems starting with Windows 2016 Server and the Windows 10 Anniversary Update, Windows therefore has native support for the PVM.PM.FILE and also NVM.PM.VOLUME interfaces. In addition, it also now natively runs the NVML (Navigation Markup Language) open source library. The Linux Community has also implemented DAX in kernel version 4.0 and has added NVDIMM detection starting with kernel 4.2. This software support is explained in great depth on the website PMEM.io. Off-the-shelf application software has waited for operating system support to be implemented before moving forward, so it will take longer to fall into place. (Such application programs are referred to as “PM-Aware.”) Custom application software like that used in hyperscale data centers already employs these operating systems since it has more flexibility and operates in a more tightly-controlled environment. As a matter of fact, hyperscale companies have been implementing systems with customized software on systems with NVDIMM-Ns for a number of years, and have participated in the standardization efforts around persistent memory software.
Some readers may be puzzled by the fact that two terms are being used for the same thing: Persistent Memory, and NVM. This is a nascent technology and multiple terms are currently popular – the industry hasn’t yet settled on a singe one. Intel has thrown its might behind the term “Persistent Memory” and several other companies are following that lead. Other terms that some of our readers may be more familiar with are “Storage Class Memory” (SCM) and “Nonvolatile Memory” or NVM. One company, Nantero, calls its new memory technology: “Memory Class Storage” although support for that term is currently limited. SNIA members noticed that many people got confused by the similarity of “NVM” and the NVMe interface, encouraging the organization to push to stop using the term “NVM” and replace it with “Persistent Memory” or “PM”.
Although SNIA first released its Nonvolatile Memory (NVM) Programming Model in 2013 The SSD Guy hasn’t covered it until now. I finally wrote this post because I expect to refer to it many times in the future. Persistent memory support is a fundamental change to software architecture, driven by a big restructuring of the memory/storage hierarchy. Leading software, processor, memory, and storage companies, trade organizations, and standards bodies, understand the significance of this change so they have joined together to mutually agree upon how applications programs should manage persistent memory. They are all devoting significant resources to assure that this software support comes into being in an orderly manner.