Hi Toshi, tj, Really sorry for the delay. There were so many discussions in this thread and it took me a lot of time to read and follow them. 2013/8/24 Toshi Kani <toshi.kani@xxxxxx>: ...... > On Sat, 2013-08-24 at 00:54 +0800, Zhang Yanfei wrote: >> > Tang, what do you think? Are you OK to try Tejun's suggestion as well? >> > We have been working on this for a while. And will send the patches soon. We are trying this idea and will see how it goes. >> >> 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? > > Right. > >> If so, yeah, we have been working on this direction. > > Great! > >> 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. >> >> Do you guys think this is reasonable and acceptable? > > Have you also looked at Yinghai's comments below? > > http://www.spinics.net/lists/linux-mm/msg61362.html > We have read the comments from Yinghai. Reordering relocated_initrd and reserve_crashkernel is doable, and the most difficult part is change the page tables initialization logic. And as Zhang has mentioned above, we are not sure if this could be acceptable. Actually I also stand with Toshi that we should get SRAT earlier. This will solve memory hotplug issue, and also the following local page table problem. And as tj concerned about the stability of the kernel boot sequence, then how about this: We don't do acpi_initrd_override() that early in head_32.S and head_64.c. We do it after early_ioremap is available. I have mentioned this before. With the help of early_ioremap, which is used by many others, we can copy all override tables into memory. In my understanding, the page tables setup by early_ioremap will work just like direct mapping page tables, right ? Then we unmap the memory, it is done. And we don't need to split the whole procedure into fnd & copy. So to tj, this approach won't affect acpica and very early boot sequence. Are you OK with this ? Thanks. -- 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>