On 08/18/2014 10:48 PM, Toshi Kani wrote:

On Sun, 2014-08-17 at 12:17 +0300, Boaz Harrosh wrote:

<>

quoted

"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 ;-)

quoted

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>