Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753395Ab3IKKFY (ORCPT ); Wed, 11 Sep 2013 06:05:24 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:28826 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751269Ab3IKKFT (ORCPT ); Wed, 11 Sep 2013 06:05:19 -0400 X-IronPort-AV: E=Sophos;i="4.90,883,1371052800"; d="scan'208";a="8489687" From: Tang Chen To: tj@kernel.org, rjw@sisk.pl, lenb@kernel.org, tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com, akpm@linux-foundation.org, trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com, mgorman@suse.de, minchan@kernel.org, mina86@mina86.com, gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com, prarit@redhat.com, zhangyanfei@cn.fujitsu.com, toshi.kani@hp.com Cc: x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-acpi@vger.kernel.org Subject: [PATCH v2 1/9] memblock: Introduce allocation direction to memblock. Date: Wed, 11 Sep 2013 18:07:29 +0800 Message-Id: <1378894057-30946-2-git-send-email-tangchen@cn.fujitsu.com> X-Mailer: git-send-email 1.7.11.7 In-Reply-To: <1378894057-30946-1-git-send-email-tangchen@cn.fujitsu.com> References: <1378894057-30946-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/09/11 18:02:50, Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/09/11 18:02:55, Serialize complete at 2013/09/11 18:02:55 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4335 Lines: 121 The Linux kernel cannot migrate pages used by the kernel. As a result, kernel pages cannot be hot-removed. So we cannot allocate hotpluggable memory for the kernel. ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info. But before SRAT is parsed, memblock has already started to allocate memory for the kernel. So we need to prevent memblock from doing this. In a memory hotplug system, any numa node the kernel resides in should be unhotpluggable. And for a modern server, each node could have at least 16GB memory. So memory around the kernel image is highly likely unhotpluggable. So the basic idea is: Allocate memory from the end of the kernel image and to the higher memory. Since memory allocation before SRAT is parsed won't be too much, it could highly likely be in the same node with kernel image. The current memblock can only allocate memory from high address to low. So this patch introduces the allocation direct to memblock. It could be used to tell memblock to allocate memory from high to low or from low to high. Signed-off-by: Tang Chen Reviewed-by: Zhang Yanfei --- include/linux/memblock.h | 22 ++++++++++++++++++++++ mm/memblock.c | 13 +++++++++++++ 2 files changed, 35 insertions(+), 0 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f388203..fbf6b6d 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -19,6 +19,11 @@ #define INIT_MEMBLOCK_REGIONS 128 +/* Allocation order. */ +#define MEMBLOCK_DIRECTION_HIGH_TO_LOW 0 +#define MEMBLOCK_DIRECTION_LOW_TO_HIGH 1 +#define MEMBLOCK_DIRECTION_DEFAULT MEMBLOCK_DIRECTION_HIGH_TO_LOW + struct memblock_region { phys_addr_t base; phys_addr_t size; @@ -35,6 +40,7 @@ struct memblock_type { }; struct memblock { + int current_direction; /* allocate from higher or lower address */ phys_addr_t current_limit; struct memblock_type memory; struct memblock_type reserved; @@ -146,6 +152,12 @@ phys_addr_t memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid) phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align); +static inline bool memblock_direction_bottom_up(void) +{ + return memblock.current_direction == MEMBLOCK_DIRECTION_LOW_TO_HIGH; +} + + /* Flags for memblock_alloc_base() amd __memblock_alloc_base() */ #define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0) #define MEMBLOCK_ALLOC_ACCESSIBLE 0 @@ -173,6 +185,16 @@ static inline void memblock_dump_all(void) } /** + * memblock_set_current_direction - Set current allocation direction to allow + * allocating memory from higher to lower + * address or from lower to higher address + * + * @direction: In which order to allocate memory. Could be + * MEMBLOCK_DIRECTION_{HIGH_TO_LOW|LOW_TO_HIGH} + */ +void memblock_set_current_direction(int direction); + +/** * memblock_set_current_limit - Set the current allocation limit to allow * limiting allocations to what is currently * accessible during boot diff --git a/mm/memblock.c b/mm/memblock.c index a847bfe..7add615 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -32,6 +32,7 @@ struct memblock memblock __initdata_memblock = { .reserved.cnt = 1, /* empty dummy entry */ .reserved.max = INIT_MEMBLOCK_REGIONS, + .current_direction = MEMBLOCK_DIRECTION_DEFAULT, .current_limit = MEMBLOCK_ALLOC_ANYWHERE, }; @@ -977,6 +978,18 @@ void __init_memblock memblock_trim_memory(phys_addr_t align) } } +void __init_memblock memblock_set_current_direction(int direction) +{ + if (direction != MEMBLOCK_DIRECTION_HIGH_TO_LOW && + direction != MEMBLOCK_DIRECTION_LOW_TO_HIGH) { + pr_warn("memblock: Failed to set allocation order. " + "Invalid order type: %d\n", direction); + return; + } + + memblock.current_direction = direction; +} + void __init_memblock memblock_set_current_limit(phys_addr_t limit) { memblock.current_limit = limit; -- 1.7.1 -- 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/