[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 -- 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>