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

[Boaz Harrosh <boaz@plexistor.com>]

On 08/18/2014 10:48 PM, Toshi Kani wrote:
> On Sun, 2014-08-17 at 12:17 +0300, Boaz Harrosh wrote:
<>
>> "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.
> 

Right

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

A bit about large page size. The principal reason of my effort here is
that at some stage I need to send pmem blocks to block-layer or network.

The PAGE == 4K is pasted all over the block stack. Do you know how those
can work together? will we need some kind of page_split thing how does
that work?

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

This is a great idea you mean that I define:
+	int mm_add_page_mapping(phys_addr_t phys_addr, size_t total_size,
+				void **o_virt_addr)

At the mm level. OK It needs a much better name.

I know of 2 more drivers that will need the use of the same interface
actually, so you are absolutely right. I didn't dare ask ;-)

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

I'm not at all familiar with the details, perhaps the Intel
guys that knows better can chip in, but from the little I
understood: Today with DDR3 these chips come up at the e820
controller, as type 12 memory and, each vendor has a driver
to drive proprietary enablement and persistence.
With DDR4 it will all be standardized, but it will not come
up through the e820 manager, but as a separate device on the
SMBus/ACPI.
So it is not clear to me that we want to plug this back into
the ARCH's memory controllers. check_hotplug_memory_range is
it per ARCH?

> Thanks,
> -Toshi
> 
> 

I will produce a new Patchset that introduces a new API
for drivers. And I will try to see about the use of
init_memory_mapping(), as long as it is not using
zones.

Do you think that the new code should sit in?
	mm/memory_hotplug.c

Thanks
Boaz

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