By using the Intel® Optane™ persistent memory (PMem) in devdax mode, it is possible to memory map such a device. Because it is byte-addressable, it does not require a file system.
The primary benefit of having a file system is that it provides secure, multi-tenancy access to persistent memory.
Devdax mode security is simplistic (based on access to the /dev/dax* device) and doesn’t provide any support for multi-tenancy. (In theory it could build its own, but then it will end up with something that looks a lot like a dax-capable file system.)
It is possible to modify the allocation library (libvmmalloc) to work with the devdax device in addition to the fsdax access it normally supports.
Note that unlike fsdax mode, where the file system plays a role in determining the page sizes used (4KB or 2MB) devdax mode uses the alignment characteristic of the Intel® Optane™ PMem itself (4KB, 2MB, or 1GB). Despite the paucity of 1GB TLB entries, 1GB alignment for devdax Intel® Optane™ PMem yields the best performance across a range of workloads. (It is never slower, sometimes as much as 68% better depending upon the workload.) The libpmem library (and libpmem2 once released) also works with devdax.
In conclusion, It is possible to just mmap it but be mindful of the limitations listed above because most PMDK libraries can simply use devdax for the pool.