On Thu, Oct 10, 2013 at 01:17:10PM -0600, Toshi Kani wrote: > In earlier discussions, Tejun pointed out that huge mappings dismiss the > benefit of local page tables. > > https://lkml.org/lkml/2013/8/23/245 This is going nowhere. If we're assuming use of large mappings, none of this matters. The pagetable is gonna be small no matter what and locating it near kernel image doesn't really impact anything whether hotplug is gonna be per-node or per-device. Short of the ability to relocate kernel image itself, parsing or not parsing SRAT early doesn't lead to anything of consequence. What are we even arguing about? That's what bothers me about this effort. Nobody seems to have actually thought it through. To summarize, * To do local page table, full ACPI device hierarchy should be parsed. * Local page table is pointless if you assume huge mappings and the plan is to assume huge mappings so that only SRAT is necessary before allocating page tables. * But if you assume huge mappings, it doesn't make material difference whether the page table is after the kernel image or near the top of non-hotpluggable memory. It's tiny anyway. * So, what's the point of pulling SRAT parsing into early boot? If we assume huge mappings, it doesn't make any material difference for either per-node or per-device unplug - it's tiny. If we don't assume huge mappings, we're talking about parsing full ACPI device tree before building pagetable. Let's say that's something we can accept. Is the benefit worthwhile? Doing all that just for debug configs? Is that something people are actually arguing for? Sure, if it works without too much effort, it's great, but do we really wanna do all that and update page table allocation so that everything is per-device just to support debug configs, for real? I'm not asking for super concrete plan but right now people working on this don't seem to have much idea of what the goals are or why they want certain things and the discussions naturally repeat themselves. FWIW, I'm getting to a point where I think nacking the whole series is the right thing to do here. 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>