Dan Williams <dan.j.williams@xxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>