From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755945Ab3AYJnw (ORCPT ); Fri, 25 Jan 2013 04:43:52 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:4762 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754932Ab3AYJnA (ORCPT ); Fri, 25 Jan 2013 04:43:00 -0500 X-IronPort-AV: E=Sophos;i="4.84,537,1355068800"; d="scan'208";a="6646218" From: Tang Chen To: akpm@linux-foundation.org, jiang.liu@huawei.com, wujianguo@huawei.com, hpa@zytor.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, linfeng@cn.fujitsu.com, yinghai@kernel.org, isimatu.yasuaki@jp.fujitsu.com, 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 Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1/3] acpi, memory-hotplug: Parse SRAT before memblock is ready. Date: Fri, 25 Jan 2013 17:42:07 +0800 Message-Id: <1359106929-3034-2-git-send-email-tangchen@cn.fujitsu.com> X-Mailer: git-send-email 1.7.10.1 In-Reply-To: <1359106929-3034-1-git-send-email-tangchen@cn.fujitsu.com> References: <1359106929-3034-1-git-send-email-tangchen@cn.fujitsu.com> X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/01/25 17:41:57, Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/01/25 17:41:59, Serialize complete at 2013/01/25 17:41:59 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On linux, the pages used by kernel could not be migrated. As a result, if a memory range is used by kernel, it cannot be hot-removed. So if we want to hot-remove memory, we should prevent kernel from using it. The way now used to prevent this is specify a memory range by movablemem_map boot option and set it as ZONE_MOVABLE. But when the system is booting, memblock will allocate memory, and reserve the memory for kernel. And before we parse SRAT, and know the node memory ranges, memblock is working. And it may allocate memory in ranges to be set as ZONE_MOVABLE. This memory can be used by kernel, and never be freed. So, let's parse SRAT before memblock is called first. And it is early enough. The first call of memblock_find_in_range_node() is in: setup_arch() |-->setup_real_mode() so, this patch add a function early_parse_srat() to parse SRAT, and call it before setup_real_mode() is called. NOTE: 1) Do not clear numa_nodes_parsed in numa_init() because SRAT was parsed earlier. 2) I don't know why using count of memory affinities parsed from SRAT as a return value in original acpi_numa_init(). So I add a static variable srat_mem_cnt to remember this count and use it as the return value of the new acpi_numa_init() Signed-off-by: Tang Chen --- arch/x86/kernel/setup.c | 13 +++++++++---- arch/x86/mm/numa.c | 2 +- drivers/acpi/numa.c | 23 +++++++++++++---------- include/linux/acpi.h | 1 + 4 files changed, 24 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 23ddd55..3787f14 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -903,6 +903,15 @@ void __init setup_arch(char **cmdline_p) setup_bios_corruption_check(); #endif + /* + * In the memory hotplug case, the kernel need info from SRAT to + * determine which memory is hotpluggable before allocating memory + * using memblock. + */ + acpi_boot_table_init(); + early_acpi_boot_init(); + early_parse_srat(); + printk(KERN_DEBUG "initial memory mapped: [mem 0x00000000-%#010lx]\n", (max_pfn_mapped<