From patchwork Tue Aug 27 09:37:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tangchen X-Patchwork-Id: 2850079 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B26D2BF546 for ; Tue, 27 Aug 2013 09:40:29 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 88C84202DD for ; Tue, 27 Aug 2013 09:40:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CD3B8202B8 for ; Tue, 27 Aug 2013 09:40:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752847Ab3H0JjR (ORCPT ); Tue, 27 Aug 2013 05:39:17 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:49294 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753256Ab3H0JjO (ORCPT ); Tue, 27 Aug 2013 05:39:14 -0400 X-IronPort-AV: E=Sophos;i="4.89,967,1367942400"; d="scan'208";a="8317104" Received: from unknown (HELO tang.cn.fujitsu.com) ([10.167.250.3]) by song.cn.fujitsu.com with ESMTP; 27 Aug 2013 17:36:03 +0800 Received: from fnstmail02.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1]) by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id r7R9d3BB008010; Tue, 27 Aug 2013 17:39:08 +0800 Received: from G08FNSTD090432.fnst.cn.fujitsu.com ([10.167.226.99]) by fnstmail02.fnst.cn.fujitsu.com (Lotus Domino Release 8.5.3) with ESMTP id 2013082717370934-987571 ; Tue, 27 Aug 2013 17:37:09 +0800 From: Tang Chen To: rjw@sisk.pl, lenb@kernel.org, tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com, akpm@linux-foundation.org, tj@kernel.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 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 05/11] memblock: Introduce allocation order to memblock. Date: Tue, 27 Aug 2013 17:37:42 +0800 Message-Id: <1377596268-31552-6-git-send-email-tangchen@cn.fujitsu.com> X-Mailer: git-send-email 1.7.11.7 In-Reply-To: <1377596268-31552-1-git-send-email-tangchen@cn.fujitsu.com> References: <1377596268-31552-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/08/27 17:37:09, Serialize by Router on mailserver/fnst(Release 8.5.3|September 15, 2011) at 2013/08/27 17:37:14, Serialize complete at 2013/08/27 17:37:14 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 order 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 | 15 +++++++++++++++ mm/memblock.c | 13 +++++++++++++ 2 files changed, 28 insertions(+), 0 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index cabd685..f233c1f 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -19,6 +19,11 @@ #define INIT_MEMBLOCK_REGIONS 128 +/* Allocation order. */ +#define MEMBLOCK_ORDER_HIGH_TO_LOW 0 +#define MEMBLOCK_ORDER_LOW_TO_HIGH 1 +#define MEMBLOCK_ORDER_DEFAULT MEMBLOCK_ORDER_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_order; /* allocate from higher or lower address */ phys_addr_t current_limit_low; /* lower boundary of accessable range */ phys_addr_t current_limit_high; /* upper boundary of accessable range */ struct memblock_type memory; @@ -174,6 +180,15 @@ static inline void memblock_dump_all(void) } /** + * memblock_set_current_order - Set the current allocation order to allow + * allocating memory from higher to lower address or + * from lower to higher address + * @order: In which order to allocate memory. Could be + * MEMBLOCK_ORDER_{HIGH_TO_LOW|LOW_TO_HIGH} + */ +void memblock_set_current_order(int order); + +/** * memblock_set_current_limit_low - Set the current allocation lower limit to * allow limiting allocations to what is currently * accessible during boot diff --git a/mm/memblock.c b/mm/memblock.c index 54c1c2e..8f1e2d4 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_order = MEMBLOCK_ORDER_DEFAULT, .current_limit_low = 0, .current_limit_high = MEMBLOCK_ALLOC_ANYWHERE, }; @@ -989,6 +990,18 @@ void __init_memblock memblock_trim_memory(phys_addr_t align) } } +void __init_memblock memblock_set_current_order(int order) +{ + if (order != MEMBLOCK_ORDER_HIGH_TO_LOW && + order != MEMBLOCK_ORDER_LOW_TO_HIGH) { + pr_warn("memblock: Failed to set allocation order. " + "Invalid order type: %d\n", order); + return; + } + + memblock.current_order = order; +} + void __init_memblock memblock_set_current_limit_low(phys_addr_t limit) { memblock.current_limit_low = limit;