On Mon, Apr 13, 2015 at 1:45 PM, Ingo Molnar <mingo(a)kernel.org> wrote:
* Christoph Hellwig <hch(a)lst.de> wrote:
> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
> > Limitations: this is a regular block device, and since the pmem areas
> > are not struct page backed, they are invisible to the rest of the
> > system (other than the block IO device), so direct IO to/from pmem
> > areas, direct mmap() or XIP is not possible yet. The page cache will
> > also shadow and double buffer pmem contents, etc.
>
> Unless you use the DAX support in ext2/4 and soon XFS, in which case
> we avoid that double buffering when doing read/write and mmap
Indeed, I missed that DAX support just went upstream in v4.0 - nice!
DAX may have some other limitations though that comes from not having
struct page * backing and using VM_MIXEDMAP, the following APIs might
not work on DAX files:
- splice
- zero copy O_DIRECT into DAX areas.
- futexes
- ( AFAICS hugetlbs won't work on DAX mmap()s yet - although with
the current nocache mapping that's probable the least of the
performance issues for now. )
mlock() and MAP_POPULATE don't work with DAX files as well.
Btw., what's the future design plan here? Enable struct page backing,
or provide special codepaths for all DAX uses like the special pte
based approach for mmap()s?
Thanks,
Ingo
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm(a)lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm