Hello, On Thu, Aug 22, 2013 at 02:11:32PM -0600, Toshi Kani wrote: > It's too late for the kernel image itself, but it prevents allocating > kernel memory from movable ranges after that. I'd say it solves a half > of the issue this time. 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. > > > Also, how do you support local page tables without pursing SRAT early? > > > > Does it even matter with huge mappings? It's gonna be contained in a > > single page anyway, right? > > Are the huge mappings always used? We cannot force user programs to use > huge pages, can we? Everything is a trade-off. Should we do all this just to support the off chance someone tries to use memory hotplug on a machine which doesn't support huge mapping when virtually all CPUs on market supports it? > As for the maintainability, I am far more concerned with your suggestion > of having a separate page table init code when SRAT is used. This kind > of divergence is a recipe of breakage. I don't buy that. The only thing which needs to change is the directionality of allocation and we probably don't even need to do that if huge mapping is in use. 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>