On Wed, 20 Apr 2011, Matthew Wilcox wrote: > > That part makes me think the best option is to make parisc do > > CONFIG_NUMA as well regardless of the historical intent was. > > But it's not just parisc. It's six other architectures as well, some > of which aren't even SMP. Does !SMP && NUMA make any kind of sense? > It does as long as DISCONTIGMEM is hijacking NUMA abstractions throughout the code; for example, look at the .config that James is probably using for testing here: CONFIG_PA8X00=y CONFIG_64BIT=y CONFIG_DISCONTIGMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_NODES_SHIFT=3 and CONFIG_NUMA is not enabled. So we want CONFIG_NODES_SHIFT of 3 (because MAX_PHYSMEM_RANGES is 8) and CONFIG_NEED_MULTIPLE_NODES is enabled because of DISCONTIGMEM: # # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's # to represent different areas of memory. This variable allows # those dependencies to exist individually. # config NEED_MULTIPLE_NODES def_bool y depends on DISCONTIGMEM || NUMA when in reality we should do away with CONFIG_NEED_MULTIPLE_NODES and just force DISCONTIGMEM to enable CONFIG_NUMA at least for -stable and as a quick fix for James. In the long run, we'll probably want to define a lighterweight CONFIG_NUMA as a layer that CONFIG_DISCONTIGMEM can use for memory range abstractions and then CONFIG_NUMA is built on top of it to define proximity between those ranges. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html