<zhangyanfei@xxxxxxxxxxxxxx>,"yanghy@xxxxxxxxxxxxxx" <yanghy@xxxxxxxxxxxxxx>,the arch/x86 maintainers <x86@xxxxxxxxxx>,"linux-doc@xxxxxxxxxxxxxxx" <linux-doc@xxxxxxxxxxxxxxx>,Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>,Linux MM <linux-mm@xxxxxxxxx>,ACPI Devel Maling List <linux-acpi@xxxxxxxxxxxxxxx> Message-ID: <aad28f9f-be10-43d8-bb98-e28d46101c44@xxxxxxxxxxxxxxxxx> BRK makes sense as long as you can set a sane O(1) size limit. Yinghai Lu <yinghai@xxxxxxxxxx> 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 ><zhangyanfei.yes@xxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>