Jan Kara <jack(a)suse.cz> writes:
[Added ext4, xfs, and linux-api folks to CC for the interface
On Tue 02-10-18 14:10:39, Johannes Thumshirn wrote:
> On Tue, Oct 02, 2018 at 12:05:31PM +0200, Jan Kara wrote:
> > Hello,
> > commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax"
> > removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
> > mean time certain customer of ours started poking into /proc/<pid>/smaps
> > and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
> > flags, the application just fails to start complaining that DAX support is
> > missing in the kernel. The question now is how do we go about this?
> OK naive question from me, how do we want an application to be able to
> check if it is running on a DAX mapping?
The question from me is: Should application really care? After all DAX is
just a caching decision. Sure it affects performance characteristics and
memory usage of the kernel but it is not a correctness issue (in particular
we took care for MAP_SYNC to return EOPNOTSUPP if the feature cannot be
supported for current mapping). And in the future the details of what we do
with DAX mapping can change - e.g. I could imagine we might decide to cache
writes in DRAM but do direct PMEM access on reads. And all this could be
auto-tuned based on media properties. And we don't want to tie our hands by
specifying too narrowly how the kernel is going to behave.
For read and write, I would expect the O_DIRECT open flag to still work,
even for dax-capable persistent memory. Is that a contentious opinion?
So, what we're really discussing is the behavior for mmap. MAP_SYNC
will certainly ensure that the page cache is not used for writes. It
would also be odd for us to decide to cache reads. The only issue I can
see is that perhaps the application doesn't want to take a performance
hit on write faults. I haven't heard that concern expressed in this
Just to be clear, this is my understanding of the world:
- file system guarantees that metadata required to reach faulted-in file
data is consistent on media before a write fault is completed. A
side-effect is that the page cache will not be used for
and what I think Dan had proposed:
mmap flag, MAP_DIRECT
- file system guarantees that page cache will not be used to front storage.
storage MUST be directly addressable. This *almost* implies MAP_SYNC.
The subtle difference is that a write fault /may/ not result in metadata
being written back to media.
and this is what I think you were proposing, Jan:
madvise flag, MADV_DIRECT_ACCESS
- same semantics as MAP_DIRECT, but specified via the madvise system call