Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753185Ab2K1IcY (ORCPT ); Wed, 28 Nov 2012 03:32:24 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:13034 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752876Ab2K1IcW (ORCPT ); Wed, 28 Nov 2012 03:32:22 -0500 X-IronPort-AV: E=Sophos;i="4.83,333,1352044800"; d="scan'208";a="6291994" Message-ID: <50B5CD9C.6010007@cn.fujitsu.com> Date: Wed, 28 Nov 2012 16:38:52 +0800 From: Wen Congyang User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jiang Liu CC: Bob Liu , Tang Chen , hpa@zytor.com, akpm@linux-foundation.org, rob@landley.net, isimatu.yasuaki@jp.fujitsu.com, laijs@cn.fujitsu.com, linfeng@cn.fujitsu.com, yinghai@kernel.org, kosaki.motohiro@jp.fujitsu.com, minchan.kim@gmail.com, mgorman@suse.de, rientjes@google.com, rusty@rustcorp.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, m.szyprowski@samsung.com Subject: Re: [PATCH v2 0/5] Add movablecore_map boot option References: <1353667445-7593-1-git-send-email-tangchen@cn.fujitsu.com> <50B479FA.6010307@cn.fujitsu.com> <50B4B6BE.3000902@cn.fujitsu.com> <50B58E30.9060804@huawei.com> <50B5CB4D.6070402@cn.fujitsu.com> <50B5CB23.8000904@huawei.com> In-Reply-To: <50B5CB23.8000904@huawei.com> X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2012/11/28 16:31:53, Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2012/11/28 16:31:54, Serialize complete at 2012/11/28 16:31:54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5506 Lines: 149 At 11/28/2012 04:28 PM, Jiang Liu Wrote: > On 2012-11-28 16:29, Wen Congyang wrote: >> At 11/28/2012 12:08 PM, Jiang Liu Wrote: >>> On 2012-11-28 11:24, Bob Liu wrote: >>>> On Tue, Nov 27, 2012 at 8:49 PM, Tang Chen wrote: >>>>> On 11/27/2012 08:09 PM, Bob Liu wrote: >>>>>> >>>>>> On Tue, Nov 27, 2012 at 4:29 PM, Tang Chen >>>>>> 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@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() > This sounds good, but the code to reserve memory for movable > nodes will be similar to dma_declare_contiguous(). Yes, it may be very similar. I think we can move it into mm/page_alloc.c, and both cma and movablecore_map can use this function. Thanks Wen Congyang > >> 3. release the memory in mem_init >> >> What about this? >> >> Thanks >> Wen Congyang >>> >>> >>> >>> >>> >> >> >> . >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/