On Wed, 2014-08-13 at 15:26 +0300, Boaz Harrosh wrote: > From: Yigal Korman <yigal@xxxxxxxxxxxxx> > > One of the current short comings of the NVDIMM/PMEM > support is that this memory does not have a page-struct(s) > associated with its memory and therefor cannot be passed > to a block-device or network or DMAed in any way through > another device in the system. > > This simple patch fixes all this. After this patch an FS > can do: > bdev_direct_access(,&pfn,); > page = pfn_to_page(pfn); > And use that page for a lock_page(), set_page_dirty(), and/or > anything else one might do with a page *. > (Note that with brd one can already do this) > > [pmem-pages-ref-count] > pmem will serve it's pages with ref==0. Once an FS does > an blkdev_get_XXX(,FMODE_EXCL,), that memory is own by the FS. > The FS needs to manage its allocation, just as it already does > for its disk blocks. The fs should set page->count = 2, before > submission to any Kernel subsystem so when it returns it will > never be released to the Kernel's page-allocators. (page_freeze) > > All is actually needed for this is to allocate page-sections > and map them into kernel virtual memory. Note that these sections > are not associated with any zone, because that would add them to > the page_allocators. Can we just use memory hotplug and call add_memory(), instead of directly calling sparse_add_one_section()? Memory hotplug adds memory as off-line state, and sets all pages reserved. So, I do not think the page allocators will mess with them (unless you put them online). It can also maps the pages with large page size. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
