On Wed, Nov 28, 2012 at 04:29:01PM +0800, Wen Congyang wrote:

At 11/28/2012 12:08 PM, Jiang Liu Wrote:

quoted

On 2012-11-28 11:24, Bob Liu wrote:

quoted

On Tue, Nov 27, 2012 at 8:49 PM, Tang Chen [off-list ref] wrote:

quoted

On 11/27/2012 08:09 PM, Bob Liu wrote:

quoted

On Tue, Nov 27, 2012 at 4:29 PM, Tang Chen[off-list ref]
wrote:

quoted

Hi Liu,


This feature is used in memory hotplug.

In order to implement a whole node hotplug, we need to make sure the
node contains no kernel memory, because memory used by kernel could
not be migrated. (Since the kernel memory is directly mapped,
VA = PA + __PAGE_OFFSET. So the physical address could not be changed.)

User could specify all the memory on a node to be movable, so that the
node could be hot-removed.

Thank you for your explanation. It's reasonable.

But i think it's a bit duplicated with CMA, i'm not sure but maybe we
can combine it with CMA which already in mainline?

Hi Liu,

Thanks for your advice. :)

CMA is Contiguous Memory Allocator, right?  What I'm trying to do is
controlling where is the start of ZONE_MOVABLE of each node. Could
CMA do this job ?

cma will not control the start of ZONE_MOVABLE of each node, but it
can declare a memory that always movable
and all non movable allocate request will not happen on that area.

Currently cma use a boot parameter "cma=" to declare a memory size
that always movable.
I think it might fulfill your requirement if extending the boot
parameter with a start address.

more info at http://lwn.net/Articles/468044/

quoted

And also, after a short investigation, CMA seems need to base on
memblock. But we need to limit memblock not to allocate memory on
ZONE_MOVABLE. As a result, we need to know the ranges before memblock
could be used. I'm afraid we still need an approach to get the ranges,
such as a boot option, or from static ACPI tables such as SRAT/MPST.

Yes, it's based on memblock and with boot option.
In setup_arch32()
    dma_contiguous_reserve(0);   => will declare a cma area using
memblock_reserve()

quoted

I'm don't know much about CMA for now. So if you have any better idea,
please share with us, thanks. :)

My idea is reuse cma like below patch(even not compiled) and boot with
"cma=size@start_address".
I don't know whether it can work and whether suitable for your
requirement, if not forgive me for this noises.

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 612afcc..564962a 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c

@@ -59,11 +59,18 @@ struct cma *dma_contiguous_default_area;
  */
 static const unsigned long size_bytes = CMA_SIZE_MBYTES * SZ_1M;
 static long size_cmdline = -1;
+static long cma_start_cmdline = -1;

 static int __init early_cma(char *p)
 {
+       char *oldp;
        pr_debug("%s(%s)\n", __func__, p);
+       oldp = p;
        size_cmdline = memparse(p, &p);
+
+       if (*p == '@')
+               cma_start_cmdline = memparse(p+1, &p);
+       printk("cma start:0x%x, size: 0x%x\n", size_cmdline, cma_start_cmdline);
        return 0;
 }
 early_param("cma", early_cma);

@@ -127,8 +134,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
        if (selected_size) {
                pr_debug("%s: reserving %ld MiB for global area\n", __func__,
                         selected_size / SZ_1M);
-
-               dma_declare_contiguous(NULL, selected_size, 0, limit);
+               if (cma_size_cmdline != -1)
+                       dma_declare_contiguous(NULL, selected_size,

cma_start_cmdline, limit);
+               else
+                       dma_declare_contiguous(NULL, selected_size, 0, limit);
        }
 };

Seems a good idea to reserve memory by reusing CMA logic, though need more
investigation here. One of CMA goal is to ensure pages in CMA are really
movable, and this patchset tries to achieve the same goal at a first glance.

Hmm, I don't like to reuse CMA. Because CMA is used for DMA. If we reuse it
for movable memory, I think movable zone is enough. And the start address is
not acceptable, because we want to specify the start address for each node.

I think we can implement movablecore_map like that:
1. parse the parameter
2. reserve the memory after efi_reserve_boot_services()
3. release the memory in mem_init

Hi Tang,

I haven't read the patchset yet, but could you give a short describe how 
you design your implementation in this patchset?

Regards,
Jaegeuk

What about this?

Thanks
Wen Congyang

quoted

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

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