linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: jiang.liu@huawei.com, wujianguo@huawei.com, hpa@zytor.com,
	akpm@linux-foundation.org, wency@cn.fujitsu.com,
	laijs@cn.fujitsu.com, linfeng@cn.fujitsu.com, yinghai@kernel.org,
	rob@landley.net, kosaki.motohiro@jp.fujitsu.com,
	minchan.kim@gmail.com, mgorman@suse.de, rientjes@google.com,
	guz.fnst@cn.fujitsu.com, rusty@rustcorp.com.au,
	lliubbo@gmail.com, jaegeuk.hanse@gmail.com, tony.luck@intel.com,
	glommer@parallels.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT.
Date: Wed, 26 Dec 2012 15:39:48 +0800	[thread overview]
Message-ID: <50DAA9C4.1040804@cn.fujitsu.com> (raw)
In-Reply-To: <50DA9ED5.4000501@jp.fujitsu.com>

On 12/26/2012 02:53 PM, Yasuaki Ishimatsu wrote:
> Hi Tang,
> 
> I don't think it can work well.
> The patch gets memory range of hotpluggable memory by
> acpi_numa_memory_affinity_init(). But it too late.
> For example, if we use log_buf_len boot options, memblock allocator
> runs before getting SRAT information. In this case, this movablecore_map
> boot option does not work well.
> 

Hi Ishimatsu-san,

Yes, you are right. After finish_e820_parsing() in setup_arch(),
memblock allocator could start to work. So we need to reserve
the hotpluggable memory before it. But SRAT parsing is far behind.
So for now, I didn't work out a suitable way to do this.

I think we need to move ACPI table parsing logic before memblock is
ready. But we need to solve how to allocate memory for ACPI table
parsing logic.

I'll try to figure out a way and start a discussion soon.

Thanks. :)

> Thanks,
> Yasuaki Ishimatsu
> 
> 2012/12/19 18:11, Tang Chen wrote:
>> The Hot Plugable bit in SRAT flags specifys if the memory range
>> could be hotplugged.
>>
>> If user specified movablecore_map=nn[KMG]@ss[KMG], reset
>> movablecore_map.map to the intersection of hotpluggable ranges from
>> SRAT and old movablecore_map.map.
>> Else if user specified movablecore_map=acpi, just use the hotpluggable
>> ranges from SRAT.
>> Otherwise, do nothing. The kernel will use all the memory in all nodes
>> evenly.
>>
>> The idea "getting info from SRAT" was from Liu Jiang<jiang.liu@huawei.com>.
>> And the idea "do more limit for memblock" was from Wu Jianguo<wujianguo@huawei.com>
>>
>> Signed-off-by: Tang Chen<tangchen@cn.fujitsu.com>
>> Tested-by: Gu Zheng<guz.fnst@cn.fujitsu.com>
>> ---
>>    arch/x86/mm/srat.c |   55 +++++++++++++++++++++++++++++++++++++++++++++++++--
>>    1 files changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
>> index 4ddf497..a8856d2 100644
>> --- a/arch/x86/mm/srat.c
>> +++ b/arch/x86/mm/srat.c
>> @@ -146,7 +146,12 @@ int __init
>>    acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>    {
>>    	u64 start, end;
>> +	u32 hotpluggable;
>>    	int node, pxm;
>> +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>> +	int overlap;
>> +	unsigned long start_pfn, end_pfn;
>> +#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
>>
>>    	if (srat_disabled())
>>    		return -1;
>> @@ -157,8 +162,10 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>    	if ((ma->flags&  ACPI_SRAT_MEM_ENABLED) == 0)
>>    		return -1;
>>
>> -	if ((ma->flags&  ACPI_SRAT_MEM_HOT_PLUGGABLE)&&  !save_add_info())
>> +	hotpluggable = ma->flags&  ACPI_SRAT_MEM_HOT_PLUGGABLE;
>> +	if (hotpluggable&&  !save_add_info())
>>    		return -1;
>> +
>>    	start = ma->base_address;
>>    	end = start + ma->length;
>>    	pxm = ma->proximity_domain;
>> @@ -178,9 +185,51 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>
>>    	node_set(node, numa_nodes_parsed);
>>
>> -	printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
>> +	printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx] %s\n",
>>    	       node, pxm,
>> -	       (unsigned long long) start, (unsigned long long) end - 1);
>> +	       (unsigned long long) start, (unsigned long long) end - 1,
>> +	       hotpluggable ? "Hot Pluggable": "");
>> +
>> +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
>> +	start_pfn = PFN_DOWN(start);
>> +	end_pfn = PFN_UP(end);
>> +
>> +	if (!hotpluggable) {
>> +		/* Clear the range overlapped in movablecore_map.map */
>> +		remove_movablecore_map(start_pfn, end_pfn);
>> +		goto out;
>> +	}
>> +
>> +	if (!movablecore_map.acpi) {
>> +		for (overlap = 0; overlap<  movablecore_map.nr_map; overlap++) {
>> +			if (start_pfn<  movablecore_map.map[overlap].end_pfn)
>> +				break;
>> +		}
>> +
>> +		/*
>> +		 * If there is no overlapped range, or the end of the overlapped
>> +		 * range is higher than end_pfn, then insert nothing.
>> +		 */
>> +		if (end_pfn<= movablecore_map.map[overlap].end_pfn)
>> +			goto out;
>> +
>> +		/*
>> +		 * Otherwise, insert the rest of this range to prevent memblock
>> +		 * from allocating memory in it.
>> +		 */
>> +		start_pfn = movablecore_map.map[overlap].end_pfn;
>> +		start = start_pfn>>  PAGE_SHIFT;
>> +	}
>> +
>> +	/* If user chose to use SRAT info, insert the range anyway. */
>> +	if (insert_movablecore_map(start_pfn, end_pfn))
>> +		pr_err("movablecore_map: too many entries;"
>> +			" ignoring [mem %#010llx-%#010llx]\n",
>> +			(unsigned long long) start,
>> +			(unsigned long long) (end - 1));
>> +
>> +out:
>> +#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
>>    	return 0;
>>    }
>>
>>
> 
> 
> 

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

  reply	other threads:[~2012-12-26  7:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-19  8:14 [PATCH v4 0/6] Add movablecore_map boot option with SRAT support Tang Chen
2012-12-19  8:14 ` [PATCH v4 1/6] x86: get pg_data_t's memory from other node Tang Chen
2012-12-19  8:14 ` [PATCH v4 2/6] page_alloc: add movablecore_map kernel parameter Tang Chen
2012-12-19  8:15 ` [PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT Tang Chen
2012-12-19  9:11   ` Tang Chen
2012-12-26  6:53     ` Yasuaki Ishimatsu
2012-12-26  7:39       ` Tang Chen [this message]
2012-12-26  8:33         ` Yasuaki Ishimatsu
2012-12-19  9:15   ` Tang Chen
2012-12-19  8:15 ` [PATCH v4 4/6] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes Tang Chen
2012-12-19  8:15 ` [PATCH v4 5/6] page_alloc: Make movablecore_map has higher priority Tang Chen
2012-12-19  8:15 ` [PATCH v4 6/6] page_alloc: Bootmem limit with movablecore_map Tang Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50DAA9C4.1040804@cn.fujitsu.com \
    --to=tangchen@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=glommer@parallels.com \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=jaegeuk.hanse@gmail.com \
    --cc=jiang.liu@huawei.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linfeng@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lliubbo@gmail.com \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@google.com \
    --cc=rob@landley.net \
    --cc=rusty@rustcorp.com.au \
    --cc=tony.luck@intel.com \
    --cc=wency@cn.fujitsu.com \
    --cc=wujianguo@huawei.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox