Recent Linux Updates to Support Persistent Memory
In the Linux operating system, several features were released to support Persistent Memory (PMEM). This brief overview of these features will provide insight into how they fit together to benefit your software development.
Dan Williams's Presentation at the 2018 Persistent Memory Summit
PMEM YouTube Playlist
I'm Andy Rudoff with Intel, and in this video, I give you a brief overview of the Linux features related to Persistent Memory, or PMem, to help you discover how they fit together to benefit your software development. This information is based on a more detailed presentation Intel's Dan Williams gave at the 2018 persistent memory summit where he described the Linux features that were added over the last couple of years in support of persistent memory. In the Linux operating system, a number of features were added in support of PMem.
These features are generic and meant to work with any PMem products on any platform architecture that supports them. In previous videos in the PMem playlist on our channel, I described the SNIA NVM programming model. It specifies a guiding principle for operating systems.
It says that persistent memory should appear to applications as files which can be memory mapped with standard file interfaces that have existed for many years. Two file systems were made persistent memory aware so they can provide the access suggested by the SNIA NVM programming model. The two file systems are called EXT4 and XFS, which are basically the two most commonly used file systems in Linux.
When mounted with a new option called DAX, an abbreviation for direct access, these file systems allow file access without the use of the system page cache. As shown in the diagram here, applications that memory map files get direct access to the PMem without the paging into DRAM that happens with traditional storage. Once an application opens a file on a PMem aware file system, it memory maps that file using a new flag that Linux added to the MMAP system call.
That flag is called map_sync as shown here, and it allows the application to negotiate with the file system, basically agreeing it is safe to flush changes to PMem using cache flush instructions instead of calling it to the kernel using the m_sync system call. The file system may decline the use of map_sync, saying that it is not safe to flush changes that way. So a correctly written application must contain the logic to call m_sync in that case, as shown in this flow diagram.
Applications that use the Persistent Memory Developer Kit, or PMDK, don't generally have to worry about these details as the PMDK libraries handle this automatically. Another component of the Linux operating system is the PM driver, which provides the traditional storage interfaces to persistent memory. This allows unmodified applications and file systems to use PMem in a way that makes it look like fast storage.
A special module called BTT, which stands for Block Translation Table, is also supplied, which makes the storage have traditional sector sizes like 512 bytes or 4k bytes, which are power fail atomic. Now you've seen a brief overview of the Linux OS features added for PMem. The Linux OS features are designed to be generic and vendor neutral.
They not only provide the SNIA programming model where PMem is exposed as memory mapped files but also traditional storage interfaces so unmodified applications are supported. You can watch Dan's full presentation at the links provided for a deeper dive on the Linux support for PMem, including his slides and more related materials on PMem. Thanks for watching. Don't forget to like this video and subscribe.