On Wed, Feb 6, 2019 at 3:17 PM Larry Bassel <larry.bassel(a)oracle.com> wrote:
Is mmaping a PMEM/DAX/fs file MAP_PRIVATE supported?
Is it something
that people are likely to want to do?
MAP_PRIVATE for file backed mappings is useful for processes to read
common data as input, but hide their writes to that data.
If it is supported, suppose I open a file in PMEM/DAX/fs, mmap it
MAP_PRIVATE, read from the memory mapped file (with memory accesses,
not the read syscall) and take a page fault which the kernel satisfies.
At this time do my page tables for the private mmaped page(s) point to the
PMEM corresponding to the file and the kernel will wait until
the page(s) is/are altered (either by me or someone else) to
copy on write and give me a different page/mapping?
For this example let's assume the filesystem already allocated
capacity for the file at the given offset, otherwise the kernel is
free to map in a zero page to cover holes in the file.
Or does the kernel avoid this by always mapping a copy of the
page(s) involved in the private mmap in the first place?
At read-fault time the page tables point to the direct PMEM page for
the file allocation, for a write fault a "System RAM" page is mapped
in place of PMEM.
In either case, is my private copy going to come from PMEM or is it
an "ordinary" page, or is this "random"? Does the program have
any choice in this (i.e. suppose I want to make sure my copied
page is persistent)?
No, the copied page will never be persisted. From the mmap() man page:
"Updates to the mapping are not visible to other processes mapping the
same file, and are not carried through to the underlying file."