43
system also tracks writes to those memory pages and schedules asynchronous I/O
operations to write the modifications back to the primary copy of the file on the storage
device. Alternatively, if the application wants to ensure updates are written back to
storage before continuing as we did in our code example, the msync system call on
Linux or FlushViewOfFile on Windows executes the flush to disk. This may cause the
operating system to suspend the program until the write finishes, similar to the file-write
operation described earlier.
This description of memory-mapped files using storage highlights some of the
disadvantages. First, a portion of the limited kernel memory page cache in main
memory is used to store a copy of the file. Second, for files that cannot fit in memory, the
application may experience unpredictable and variable pauses as the operating system
moves pages between memory and storage through I/O operations. Third, updates to
the in-memory copy are not persistent until written back to storage so can be lost in the
event of a failure.
Persistent Memory Direct Access (DAX)
The persistent memory direct access feature in operating systems, referred to as DAX in
Linux and Windows, uses the memory-mapped file interfaces described in the previous
section but takes advantage of persistent memory’s native ability to both store data
and to be used as memory. Persistent memory can be natively mapped as application
memory, eliminating the need for the operating system to cache files in volatile main
memory.
To use DAX, the system administrator creates a file system on the persistent memory
module and mounts that file system into the operating system’s file system tree. For
Linux users, persistent memory devices will appear as /dev/pmem* device special files. To
show the persistent memory physical devices, system administrators can use the ndctl
and ipmctl utilities shown in Listings 3-3 and 3-4.
Chapter 3 Operating SyStem SuppOrt fOr perSiStent memOry
system also tracks writes to those memory pages and schedules asynchronous I/O
operations to write the modifications back to the primary copy of the file on the storage
device. Alternatively, if the application wants to ensure updates are written back to
storage before continuing as we did in our code example, the msync system call on
Linux or FlushViewOfFile on Windows executes the flush to disk. This may cause the
operating system to suspend the program until the write finishes, similar to the file-write
operation described earlier.
This description of memory-mapped files using storage highlights some of the
disadvantages. First, a portion of the limited kernel memory page cache in main
memory is used to store a copy of the file. Second, for files that cannot fit in memory, the
application may experience unpredictable and variable pauses as the operating system
moves pages between memory and storage through I/O operations. Third, updates to
the in-memory copy are not persistent until written back to storage so can be lost in the
event of a failure.
Persistent Memory Direct Access (DAX)
The persistent memory direct access feature in operating systems, referred to as DAX in
Linux and Windows, uses the memory-mapped file interfaces described in the previous
section but takes advantage of persistent memory’s native ability to both store data
and to be used as memory. Persistent memory can be natively mapped as application
memory, eliminating the need for the operating system to cache files in volatile main
memory.
To use DAX, the system administrator creates a file system on the persistent memory
module and mounts that file system into the operating system’s file system tree. For
Linux users, persistent memory devices will appear as /dev/pmem* device special files. To
show the persistent memory physical devices, system administrators can use the ndctl
and ipmctl utilities shown in Listings 3-3 and 3-4.
Chapter 3 Operating SyStem SuppOrt fOr perSiStent memOry