The current state of persistent memory enabling in Linux is that a physical memory range discovered by a device driver is exposed to the system as a block device. That block device has the added property of being capable of DAX which, at its core, allows converting storage-device-sectors allocated to a file into pages that can be mmap()ed, DMAed, etc... In that quick two sentence summary the impacted kernel sub-systems span mm, fs, block, and a device-driver. As a result when a persistent memory design question arises there are mm, fs, block, and device-driver specific implications to consider. Are there existing persistent memory handling features that could be better handled with a more "memory" vs "device" perspective? What are we trading off? More importantly how do our current interfaces hold up when considering new features? For example, how to support DAX in coordination with the BTT (atomic sector update) driver. That might require a wider interface than the current bdev_direct_access() to tell the BTT driver when it is free to remap the block. A wider ranging example, there are some that would like to see high capacity persistent memory as just another level in a system's volatile-memory hierarchy. Depending on whom you ask that pmem tier looks like either page cache extensions, reworked/optimized swap, or a block-device-cache with DAX capabilities. For LSF/MM, with all the relevant parties in the room, it would be useful to share some successes/pain-points of the direction to date and look at the interfaces/coordination we might need between sub-systems going forward. Especially with respect to supporting pmem as one of a set of new performance differentiated memory types that need to be considered by the mm sub-system. --- As a maintainer for libnvdimm I'm interested in participating in the "Persistent Memory Error Handling" from Jeff. I'm also interested in the "HMM (heterogeneous memory manager) and GPU" topic from Jerome as it relates to mm handling of performance differentiated memory types. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
