From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx175.postini.com [74.125.245.175]) by kanga.kvack.org (Postfix) with SMTP id 042D56B0032 for ; Fri, 23 Aug 2013 14:26:41 -0400 (EDT) Message-Id: <201308231825.r7NIPQl5015165@mail.zytor.com> In-Reply-To: References: <20130821204041.GC2436@htj.dyndns.org> <1377124595.10300.594.camel@misato.fc.hp.com> <20130822033234.GA2413@htj.dyndns.org> <1377186729.10300.643.camel@misato.fc.hp.com> <20130822183130.GA3490@mtj.dyndns.org> <1377202292.10300.693.camel@misato.fc.hp.com> <20130822202158.GD3490@mtj.dyndns.org> <1377205598.10300.715.camel@misato.fc.hp.com> <20130822212111.GF3490@mtj.dyndns.org> <1377209861.10300.756.camel@misato.fc.hp.com> <20130823130440.GC10322@mtj.dyndns.org> <1377274448.10300.777.camel@misato.fc.hp.com> <521793BB.9080605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier. From: "H. Peter Anvin" Date: Fri, 23 Aug 2013 20:25:13 +0200 Sender: owner-linux-mm@kvack.org List-ID: To: Yinghai Lu , Zhang Yanfei Cc: Toshi Kani , Tejun Heo , Tang Chen , Konrad Rzeszutek Wilk , Bob Moore , Lv Zheng , "Rafael J. Wysocki" , Len Brown , Thomas Gleixner , Ingo Molnar , Andrew Morton , 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@zytor.com ,"yanghy@cn.fujitsu.com" ,the arch/x86 maintainers ,"linux-doc@vger.kernel.org" ,Linux Kernel Mailing List ,Linux MM ,ACPI Devel Maling List Message-ID: BRK makes sense as long as you can set a sane O(1) size limit. Yinghai Lu wrote: >[trimmed the CC list, assume too long list will not go through LKML] > >On Fri, Aug 23, 2013 at 9:54 AM, Zhang Yanfei > wrote: > > > >> By saying TJ's suggestion, you mean, we will let memblock to control >the >> behaviour, that said, we will do early allocations near the kernel >image >> range before we get the SRAT info? > >put the acpi override table in BRK, we still need ok from HPA. >I have impression that he did not like it, so want to confirm from him. > >> >> If so, yeah, we have been working on this direction. By doing this, >we may >> have two main changes: >> >> 1. change some of memblock's APIs to make it have the ability to >allocate >> memory from low address. >> 2. setup kernel page table down-top. Concretely, we first map the >memory >> just after the kernel image to the top, then, we map 0 - kernel >image end. > >how about kexec/kdump ? > >when load high with kexec/dump, the second kernel could be very high >near >TOHM. > >> >> Do you guys think this is reasonable and acceptable? > >current boot flow that need to have all cpu and mem and pci discovered >are not scalable. > >for numa system, we should boot system with cpu/mem/pci in PXM(X) only. >and assume that PXM are not hot-removed later. >Later during booting late stage hot add other PXM in parallel. > >That case, we could reduce boot time, and also could solve other PXM >hotplug problem. > >Thanks > >Yinghai -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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