From patchwork Thu Sep 26 22:52:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 2951691 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 65FA3BFF0B for ; Thu, 26 Sep 2013 22:52:12 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 82491202A1 for ; Thu, 26 Sep 2013 22:52:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A76B520295 for ; Thu, 26 Sep 2013 22:52:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754220Ab3IZWwJ (ORCPT ); Thu, 26 Sep 2013 18:52:09 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:35549 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751860Ab3IZWwI (ORCPT ); Thu, 26 Sep 2013 18:52:08 -0400 Received: from akpm3.mtv.corp.google.com (unknown [216.239.45.95]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id AA7A9892; Thu, 26 Sep 2013 22:52:06 +0000 (UTC) Date: Thu, 26 Sep 2013 15:52:05 -0700 From: Andrew Morton To: Zhang Yanfei Cc: "Rafael J . Wysocki" , lenb@kernel.org, Thomas Gleixner , mingo@elte.hu, "H. Peter Anvin" , Tejun Heo , Toshi Kani , Wanpeng Li , Thomas Renninger , Yinghai Lu , Jiang Liu , Wen Congyang , Lai Jiangshan , isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com, Mel Gorman , Minchan Kim , mina86@mina86.com, gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com, Rik van Riel , jweiner@redhat.com, prarit@redhat.com, "x86@kernel.org" , linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" , Linux MM , linux-acpi@vger.kernel.org, imtangchen@gmail.com, Zhang Yanfei Subject: Re: [PATCH v5 4/6] x86/mem-hotplug: Support initialize page tables in bottom-up Message-Id: <20130926155205.7f364b64c4a0fae77d4ca15d@linux-foundation.org> In-Reply-To: <5241DA5B.8000909@gmail.com> References: <5241D897.1090905@gmail.com> <5241DA5B.8000909@gmail.com> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,KHOP_BIG_TO_CC, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham 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 On Wed, 25 Sep 2013 02:30:51 +0800 Zhang Yanfei wrote: > From: Tang Chen > > 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. > > 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. > > 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. > > So direct memory mapping page tables setup is the case. init_mem_mapping() > is called before SRAT is parsed. To prevent page tables being allocated > within hotpluggable memory, we will use bottom-up direction to allocate > page tables from the end of kernel image to the higher memory. > > ... > > + kernel_end = __pa_symbol(_end); __pa_symbol() is implemented only on mips and x86. I stole the mips implementation like this: just so I can get a -mm release out the door. --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/mm/memblock.c~a +++ a/mm/memblock.c @@ -187,8 +187,11 @@ phys_addr_t __init_memblock memblock_fin /* avoid allocating the first page */ start = max_t(phys_addr_t, start, PAGE_SIZE); end = max(start, end); +#ifdef CONFIG_X86 kernel_end = __pa_symbol(_end); - +#else + kernel_end = __pa(RELOC_HIDE((unsigned long)(_end), 0)); +#endif /* * try bottom-up allocation only when bottom-up mode * is set and @end is above the kernel image.