[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA_GA1fE0fhLVs50rRZ6OsTw7DV0hyVC2EuRyUrbzxLztPLoeg@mail.gmail.com>
Date: Wed, 28 Nov 2012 11:24:34 +0800
From: Bob Liu <lliubbo@...il.com>
To: Tang Chen <tangchen@...fujitsu.com>
Cc: hpa@...or.com, akpm@...ux-foundation.org, rob@...dley.net,
isimatu.yasuaki@...fujitsu.com, laijs@...fujitsu.com,
wency@...fujitsu.com, linfeng@...fujitsu.com, jiang.liu@...wei.com,
yinghai@...nel.org, kosaki.motohiro@...fujitsu.com,
minchan.kim@...il.com, mgorman@...e.de, rientjes@...gle.com,
rusty@...tcorp.com.au, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-doc@...r.kernel.org,
m.szyprowski@...sung.com
Subject: Re: [PATCH v2 0/5] Add movablecore_map boot option
On Tue, Nov 27, 2012 at 8:49 PM, Tang Chen <tangchen@...fujitsu.com> wrote:
> On 11/27/2012 08:09 PM, Bob Liu wrote:
>>
>> On Tue, Nov 27, 2012 at 4:29 PM, Tang Chen<tangchen@...fujitsu.com>
>> wrote:
>>>
>>> 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/
>
> 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()
> 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@...rt_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);
}
};
--
Regards,
--Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists