From WikiChip
Difference between revisions of "snia/npm"

(npm)
 
(Typo)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
{{title|NVM Programming Model (NPM) - SNIA}}
 
{{title|NVM Programming Model (NPM) - SNIA}}
−
The '''NVM Programming Model''' ('''NPM''') is a set of specifications developed by the [[SNIA]] NVM Programming Technical Working Group that defines recommanded behavior between various user space and kernel components supporting [[storage-class memory]].
+
The '''NVM Programming Model''' ('''NPM''') is a set of specifications developed by the [[SNIA]] NVM Programming Technical Working Group that defines recommended behavior between various user space and kernel components supporting [[storage-class memory]].
 +
 
 +
== Motivations ==
 +
[[Persistent memory]] differs from standard [[DRAM]] in a great number of ways. Unlike traditional [[volatile memory]] which receives an anonymous region of memory, regions of persistent memory are owned by certain applications - much like files on the hard drive. There is a need to keep track of which application has access to which region of the persistent memory which can remain beyond the lifetime of the program's execution. With the commercialization of new [[storage-class memory]], it becomes necessary to formally define the semantics of working with persistent memory regions. The NVM Programming Model (NPM) addresses this by defining the formal semantics for working with such devices. The Storage Networking Industry Association (SNIA) Technical Working Group (TWG) is the group heading the specification of the persistent memory programming model.
 +
 
 +
== Overview ==
 +
NPM defines the semantics for a [[persistent memory-aware file system]]. The model uses the same standard file semantics the industry has been using for 30-some years and apply it to persistent memory, providing it with the necessary facilities for managing permissions, as well as reading and writing block storage.
 +
 
 +
{| class="wikitable"
 +
! colspan="2" | Basic File APIs
 +
|-
 +
| Windows || Linux
 +
|-
 +
| <code>OpenFile()</code>/<code>Createfile()</code><br><code>ReadFile()</code>/<code>WriteFile()</code>
 +
| <code>open()</code><br><code>read()/write()</code>
 +
|}
 +
 
 +
Additionally, there is also support for mapping memory regions to applications, providing an even more efficient way of accessing persistent memory storage. This feature is also known as {{snia|direct access}} or {{snia|DAX}} (note the term is used by both [[Linux]] and [[Windows]]). Memory-mapping a file can only be done once the file has already been created/opened, thereby already undergone the necessary permission checks. Memory-mapping a persistent file is done using the same function calls that already exist on both Windows and Linux. From the software point of view, the storage new becomes byte-addressable storage.
 +
 
 +
{| class="wikitable"
 +
! colspan="2" | [[Memory-mapped file]] APIs
 +
|-
 +
| Windows || Linux
 +
|-
 +
| <code>CreateFileMapping()</code><br><code>MapViewOfFile()</code>
 +
| <code>mmap()</code>
 +
|}
 +
[[File:snia npm dax.png|thumb|right|DAX allows direct byte-level access to the NVDIMM.]]
 +
Traditional file I/O operates on [[block storage]]. Reading a single byte from a file involves reading an entire block (typically around 4 KiB in size). Likewise, flushing the data back to persistence, the full block has to be written out. With a [[persistent memory-aware file system]], although the API remains the same, the operating system is aware of the persistent memory device and allows for direct byte-level access with the [[NVDIMM]] instead of block-level accesses.
 +
 
 +
The quickest way to do this is by simply calling <code>MapViewOfFile()</code>/<code>mmap()</code> which will provide the program with direct load/store accesses. No context switching or interrupts are needed for those accesses. It's worth noting that a small caveat to this is that the system is not required to write the modifications back immediately. 
 +
 
 +
To ease software support as well as to reduce code overhead required to take advantage of the persistent memory, NPM introduced the optional support for ''Optimized Flush'', an ability for software to flush persistence directly from userspace, without intervening the kernel. Companies such as [[Intel]] support this through the introduction of new flushing instructions (e.g., see [[x86]]'s {{x86|persistent memory extensions}}).
 +
 
 +
{| class="wikitable"
 +
! colspan="2" | Flushing APIs
 +
|-
 +
| Windows || Linux
 +
|-
 +
| <code>FlushViewOfFile()</code><br><code>FlushFileBuffers()</code>
 +
| <code>msync()</code><br><code>fsync()</code>
 +
|}
 +
 
 +
== Libraries ==
 +
* Intel's [https://pmem.io/pmdk/ Persistent Memory Development Kit] (PMDK)
  
 
== Documents ==
 
== Documents ==
 
* [https://www.snia.org/sites/default/files/NVMProgrammingModel_v1.pdf NVM Programming Model (NPM), Version 1. 2013.]
 
* [https://www.snia.org/sites/default/files/NVMProgrammingModel_v1.pdf NVM Programming Model (NPM), Version 1. 2013.]
 +
 +
== See also ==
 +
* x86's {{x86|Persistent Memory Extensions}}

Latest revision as of 17:54, 1 October 2024

The NVM Programming Model (NPM) is a set of specifications developed by the SNIA NVM Programming Technical Working Group that defines recommended behavior between various user space and kernel components supporting storage-class memory.

Motivations[edit]

Persistent memory differs from standard DRAM in a great number of ways. Unlike traditional volatile memory which receives an anonymous region of memory, regions of persistent memory are owned by certain applications - much like files on the hard drive. There is a need to keep track of which application has access to which region of the persistent memory which can remain beyond the lifetime of the program's execution. With the commercialization of new storage-class memory, it becomes necessary to formally define the semantics of working with persistent memory regions. The NVM Programming Model (NPM) addresses this by defining the formal semantics for working with such devices. The Storage Networking Industry Association (SNIA) Technical Working Group (TWG) is the group heading the specification of the persistent memory programming model.

Overview[edit]

NPM defines the semantics for a persistent memory-aware file system. The model uses the same standard file semantics the industry has been using for 30-some years and apply it to persistent memory, providing it with the necessary facilities for managing permissions, as well as reading and writing block storage.

Basic File APIs
Windows Linux
OpenFile()/Createfile()
ReadFile()/WriteFile() 		open()
read()/write()

Additionally, there is also support for mapping memory regions to applications, providing an even more efficient way of accessing persistent memory storage. This feature is also known as direct access or DAX (note the term is used by both Linux and Windows). Memory-mapping a file can only be done once the file has already been created/opened, thereby already undergone the necessary permission checks. Memory-mapping a persistent file is done using the same function calls that already exist on both Windows and Linux. From the software point of view, the storage new becomes byte-addressable storage.

Memory-mapped file APIs
Windows Linux
CreateFileMapping()
MapViewOfFile() 		mmap()
DAX allows direct byte-level access to the NVDIMM.

Traditional file I/O operates on block storage. Reading a single byte from a file involves reading an entire block (typically around 4 KiB in size). Likewise, flushing the data back to persistence, the full block has to be written out. With a persistent memory-aware file system, although the API remains the same, the operating system is aware of the persistent memory device and allows for direct byte-level access with the NVDIMM instead of block-level accesses.

The quickest way to do this is by simply calling MapViewOfFile()/mmap() which will provide the program with direct load/store accesses. No context switching or interrupts are needed for those accesses. It's worth noting that a small caveat to this is that the system is not required to write the modifications back immediately.

To ease software support as well as to reduce code overhead required to take advantage of the persistent memory, NPM introduced the optional support for Optimized Flush, an ability for software to flush persistence directly from userspace, without intervening the kernel. Companies such as Intel support this through the introduction of new flushing instructions (e.g., see x86's persistent memory extensions).

Flushing APIs
Windows Linux
FlushViewOfFile()
FlushFileBuffers() 		msync()
fsync()

Libraries[edit]

Documents[edit]

See also[edit]

Retrieved from "https://en.wikichip.org/w/index.php?title=snia/npm&oldid=102571"