> I wouldn't call it a limitation so much as a subtle dependency. All of > the current platforms that are supporting NUMA are doing so along with > ARCH_POPULATES_NODE_MAP, so in those cases making the early_node_map > dependence explicit and generic will permit the killing off of > architecture-private data structures and accounting for region sizes and > node mappings. > > The NUMA platforms that do not currently follow the > ARCH_POPULATES_NODE_MAP semantics seem to already be in various states of > disarray (generically broken, bitrotted, etc.). To that extent, perhaps > it's also useful to have NUMA imply ARCH_POPULATES_NODE_MAP? New > architectures that are going to opt for sparsemem or NUMA are likely > going to end up down the ARCH_POPULATES_NODE_MAP path anyways I would > imagine. Ok so I had a chat with Dave and it looks like that won't do for sparc. They don't really have ranges. Or rather, they do in HW, but with their hypervisor, you can get the pages all scattered in what they call "real memory", so early_node_map[] doesn't work well. So I'll rollback my changes in that area for now, put back the arch callback, but I'll keep at hand a default variant that uses early_node_map[] for the like of us. Cheers, Ben. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>