Re: [RFC 9/9] prd: Add support for page struct mapping

[Toshi Kani <toshi.kani@hp.com>]

On Sun, 2014-08-17 at 12:17 +0300, Boaz Harrosh wrote:
> On 08/15/2014 11:28 PM, Toshi Kani wrote:
> > On Wed, 2014-08-13 at 15:26 +0300, Boaz Harrosh wrote:
> >> From: Yigal Korman <yigal@plexistor.com>
 :
> >> 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
> > 
> 
> Thank you Toshi for your reply
> 
> I was thinking about that as well at first, but I was afraid, once I call
> add_memory() what will prevent the user from enabling that memory through the sysfs
> interface later, it looks to me that add_memory() will add all the necessary knobs
> to do it.
> 
> It is very important to keep a clear distinction, pmem is *not* memory what-so-ever
> it is however memory-mapped and needs these accesses enabled for it, hence the need
> for page-struct so we can DMA it off the buss.
> 
> I am very afraid of any thing that will associate a "zone" with this memory.
> Also the:
> 	firmware_map_add_hotplug(start, start + size, "System RAM");
> 
> "System RAM" it is not. 

I think add_memory() can be easily extended (or modified to provide a
separate interface) for persistent memory, and avoid creating the sysfs
interface and change the handling with firmware_map.  But I can also see
your point that persistent memory should not be added to zone at all.

Anyway, I am a bit concerned with the way to create direct mappings with
map_vm_area() within the prd driver.  Can we use init_memory_mapping()
as it's used by add_memory() and supports large page size?  The size of
persistent memory will grow up quickly.  Also, I'd prefer to have an mm
interface that takes care of page allocations and mappings, and avoid a
driver to deal with them.

> And also I think that for DDR4 NvDIMMs we will fail with:
> 	ret = check_hotplug_memory_range(start, size);
> 

Can you elaborate why DDR4 will fail with the function above?

Thanks,
-Toshi


--
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>