Skip to content

RFC New MAP_PMEM_AWARE mmap flag

Boaz Harrosh linux-mm linux-nfs 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest2 patches 66 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2mmap: Define a new MAP_PMEM_AWARE mmap flaginclude/linux/mm.h include/uapi/asm-generic/mman.h mm/mmap.c+4 -00 replies
2/2dax: Support MAP_PMEM_AWARE mmap flagfs/dax.c+9 -50 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC 0/2] New MAP_PMEM_AWARE mmap flag

Hi all

Recent DAX code fixed the cl_flushing ie durability of mmap access of direct persistent-memory from applications. It uses the radix-tree per inode to track the indexes of a file that where page-faulted for write. Then at m/fsync time it would cl_flush these pages and clean the radix-tree, for the next round.

Sigh, that is life, for legacy applications this is the price we must pay. But for NV aware applications like nvml library, we pay extra extra price, even if we do not actually call m/fsync eventually. For these applications these extra resources and especially the extra radix locking per page-fault, costs a lot, like x3 a lot.

What we propose here is a way for those applications to enjoy the boost and still not sacrifice any correctness of legacy applications. Any concurrent access from legacy apps vs nv-aware apps even to the same file / same page, will work correctly.

We do that by defining a new MMAP flag that is set by the nv-aware app. this flag is carried by the VMA. In the dax code we bypass any radix handling of the page if this flag is set. Those pages accessed *without* this flag will be added to the radix-tree, those with will not. At m/fsync time if the radix tree is then empty nothing will happen.

These are very simple none intrusive patches with minimum risk. (I think) They are based on v4.5-rc5. If you need a rebase on any other tree please say.

Please consider this new flag for those of us people who specialize in persistent-memory setups and want to extract any possible mileage out of our systems.

Also attached for reference a 3rd patch to the nvml library to use
the new flag. Which brings me to the issue of persistent_memcpy / persistent_flush. Currently this library is for x86_64 only, using the movnt instructions. The gcc compiler should have a per ARCH facility for durable memory accesses. So applications can be portable across systems.

Please advise?

list of patches:
[RFC 1/2] mmap: Define a new MAP_PMEM_AWARE mmap flag [RFC 2/2] REVIEWME: dax: Support MAP_PMEM_AWARE for optimal

Two Kernel patches

[RFC 1/1] util: add pmem-aware flag to mmap

A patch for the nvml library

Thanks
Boaz

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>