Non-Volatile Memory Programming

January 29, 2013, SNIA Non-Volatile Memory Summit, Santa Clara, CA—Andy Rudoff from Intel the special requirements for programming NVMs. The technologies are capable of much greater bandwidth, reduced latency, and are creating a new storage classification; persistent memory.

This new set of functions is able to retain data through power cycles and other upset events in the system. The new features and performance far outweigh the standard storage models, where the bottleneck is SCSI. A hybrid of storage and memory can address the needs of both areas, but needs standards and a programming model for the full ecosystem.

One important aspect is to start out with a clean slate, and avoid apps and API proliferation, as well as vendor lock-in. one set of goals is to develop a common ecosystem that still allows for innovation through evolutionary paths and flexibility. Such a programming model would specify capabilities but not encode an API, but just define the necessary syntax. OS vendors could develop their own APIs that work with their kernel. As a result, no single API would be available for all operating systems.

A generic model and an API per operating system cold create an extensible programming model that addresses the concepts of synchronous and asynchronous I/O. users could memory map names, backup, etc. through the multiple API per kernels and allow dedicated user spaces and simplified management.

Block and system I/O have been unchanged for decades. Some of the newer functions like trim have emerged for SSDs, but are still challenge to manage. Even this function is fairly undefined in many areas, such as fill the spaces with random values, all zeros, or just keep the old data without a clean pointer. The return value is an unknown, and filing memory with new data actually reduces the drive lifetime. The SSDs really need a new file system for block stacks that anticipates usage patterns, allows for submitting “fused” block commands, and addresses the I/O barriers and other HDD-related problems.

The new memory types will call for new memory allocations. The traditional approach is to have blocks of RAM allocated to an application, and the system reclaims the block when the app exits. For persistent memory, the issues include apps may be reattached to memory. As a result, the new memory structures need permission models per region that allow resizing, removing, backup, etc.

The file model has to allow functions like open, map, sync, and address the other issues of standard memory allocations. The new memory model may require the OS to control permissions versus some type of global object store. The new memory model has to address SSDs, I/O to an application buffer, memory mapped storage, and a new asynchronous I/O API.

Components will have to discover the hardware capabilities such as the size of an untearable write block —the amount of memory that will be transferred in the event of an upset in the system before all power is lost. An app has to query the hardware and define “names” for features with well defined, extensible semantics such as capacity, performance, latency, etc. these will be of the same nature as NVM express capabilities and semantics.

Any new memory model needs to develop standards and communities. The OS vendors like Windows, Linux, etc. need to help to define the programming model along with the non-volatile memory makers and users.