A bit of addition. On Thu, Aug 22, 2013 at 04:21:58PM -0400, Tejun Heo wrote: > That works if such half solution eventually leads to the full > solution. This is just a distraction. You are already too late in > the boot sequence. It doesn't even qualify as a half solution. It's > like obsessing about a speck on your shirt without your trousers on. > If you want to solve this, do that from a place where it actually is > solvable. Seriously, what's the end game here? How do you guys see this eventually reaching full solution? If you don't see that and this kinda-sorta-working solution is fine, then that's fine too but we aren't gonna make a lot of invasive changes for that. If you can at least envision the full solution, please try to fit this effort into the bigger picture. In all possible solutions that I can think of, there needs to be earlier handling of SRAT informtaion before the kernel proper starts executing be that either the actual bootloader or earlier kernel serving as kexec host. If a proper solution needs such processing earlier anyway, it can set up things so that either the default booting behavior doesn't harm hotpluggability or feed the necessary information to the kernel. In both cases, doing ACPI super early in the booting kernel doesn't buy us anything. So, then, what the hell are we doing here with all these relocations, careful double execution of the same code from different execution contexts, worrying about initrd firmware override even before the kernel page table is set up? If we're doing all those to just make the temporary half-assed-anyway solution minutely better, that's just plain stupid. Thanks. -- tejun -- 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>