Re: [-mm PATCH v2 00/25] get_user_pages() for dax pte and pmd mappings

[Jeff Moyer <jmoyer@redhat.com>]

Dan Williams <dan.j.williams@intel.com> writes:

> Summary:
>
> To date, we have implemented two I/O usage models for persistent memory,
> PMEM (a persistent "ram disk") and DAX (mmap persistent memory into
> userspace).  This series adds a third, DAX-GUP, that allows DAX mappings
> to be the target of direct-i/o.  It allows userspace to coordinate
> DMA/RDMA from/to persistent memory.
>
> The implementation leverages the ZONE_DEVICE mm-zone that went into
> 4.3-rc1 (also discussed at kernel summit) to flag pages that are owned
> and dynamically mapped by a device driver.  The pmem driver, after
> mapping a persistent memory range into the system memmap via
> devm_memremap_pages(), arranges for DAX to distinguish pfn-only versus
> page-backed pmem-pfns via flags in the new pfn_t type.

So, this basically means that an admin has to decide whether or not DMA
will be used on a given device before making a file system on it.  That
seems like an odd requirement.  There's also a configuration option of
whether to put those backing struct pages into DRAM or PMEM (which, of
course, will be dictated by the size of pmem).  I really think we should
reconsider this approach.

First, the admin shouldn't have to choose whether or not DMA will be
done on the file system.  Second, eating up storage space to track
mostly unused struct pages seems like a waste.  Is there no future for
the "introduce __pfn_t, evacuate struct page from sgls"[1] approach?
And if not, is there some other way we can solve this problem?  I know
dynamic allocation of struct pages is scary, but is it more tractable
than no pages for DMA?

Cheers,
Jeff

[1] https://lwn.net/Articles/647404/

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