From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx171.postini.com [74.125.245.171]) by kanga.kvack.org (Postfix) with SMTP id D20C46B0031 for ; Fri, 9 Aug 2013 19:57:13 -0400 (EDT) Message-ID: <520581BF.5080404@zytor.com> Date: Fri, 09 Aug 2013 16:56:47 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH part4 4/4] x86, acpi, numa, mem_hotplug: Find hotpluggable memory in SRAT memory affinities. References: <1375954883-30225-1-git-send-email-tangchen@cn.fujitsu.com> <1375954883-30225-5-git-send-email-tangchen@cn.fujitsu.com> <5204B74B.4050805@cn.fujitsu.com> <52057E8A.70601@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Yinghai Lu Cc: Tang Chen , Bob Moore , Lv Zheng , "Rafael J. Wysocki" , Len Brown , Thomas Gleixner , Ingo Molnar , Andrew Morton , Tejun Heo , Thomas Renninger , Jiang Liu , Wen Congyang , Lai Jiangshan , Yasuaki Ishimatsu , Taku Izumi , Mel Gorman , Minchan Kim , mina86@mina86.com, gong.chen@linux.intel.com, Vasilis Liaskovitis , lwoodman@redhat.com, Rik van Riel , jweiner@redhat.com, Prarit Bhargava , Zhang Yanfei , yanghy@cn.fujitsu.com, the arch/x86 maintainers , "linux-doc@vger.kernel.org" , Linux Kernel Mailing List , Linux MM , ACPI Devel Maling List On 08/09/2013 04:53 PM, Yinghai Lu wrote: > On Fri, Aug 9, 2013 at 4:43 PM, H. Peter Anvin wrote: >> On 08/09/2013 04:39 PM, Yinghai Lu wrote: >>>>> >>>>> Also parse srat table two times looks silly. >>>> >>>> By parsing SRAT twice, I can avoid memory allocation for acpi_tables_addr >>>> in acpi_initrd_override_copy() procedure at such an early time. This memory >>>> could also be in hotpluggable area. >>> >>> You already mark kernel position to be not hot-plugged, so near the >>> kernel range should be safe to be put override acpi tables. >>> >>> also what I mean parse srat two times: >>> parse to get hotplug range, and late parse other numa info again. >>> >> >> Doing two passes over a small data structure (SRAT) would seem more >> sensible than allocating memory just to avoid that... > > for x86 there is some numa info discovery path, and there are chance > srat is wrong but still have hotplug range there, or numa finally is using other > way or not used. Inconsistency looks weird. > > numa_meminfo is static struct, we have way to get final numa info early enough > before we need use memblock to alloc buffer with it. > Now, for kernel-generated data if you can define a sensible maximum you can put it in brk, if not, you have a serious problem. -hpa -- 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: email@kvack.org