![]() | |||||||||||||
Messages in this thread |
On Wed, 2005-05-04 at 21:31 -0500, Olof Johansson wrote: > On Wed, May 04, 2005 at 09:29:57PM +0100, Andy Whitcroft wrote: > > diff -X /home/apw/brief/lib/vdiff.excl -rupN reference/arch/ppc64/Kconfig current/arch/ppc64/Kconfig > > --- reference/arch/ppc64/Kconfig 2005-05-04 20:54:50.000000000 +0100 > > +++ current/arch/ppc64/Kconfig 2005-05-04 20:54:50.000000000 +0100 > > @@ -212,8 +212,8 @@ config ARCH_FLATMEM_ENABLE > > source "mm/Kconfig" > > > > config HAVE_ARCH_EARLY_PFN_TO_NID > > - bool > > - default y > > + def_bool y > > + depends on NEED_MULTIPLE_NODES > > Ok, time to show my lack of undestanding here, but when can we ever be > CONFIG_NUMA and NOT need multiple nodes? NEED_MULTIPLE_NODES is for DISCONTIG || NUMA. It is a blanket config option that helps us separate those two very intertwined options. > > @@ -481,6 +483,7 @@ static void __init setup_nonnuma(void) > > > > for (i = 0 ; i < top_of_ram; i += MEMORY_INCREMENT) > > numa_memory_lookup_table[i >> MEMORY_INCREMENT_SHIFT] = 0; > > + memory_present(0, 0, init_node_data[0].node_end_pfn); > > Isn't the memory_present stuff and numa_memory_lookup_table two > implementations doing the same thing (mapping memory to nodes)? They have similar functions: record the physical layout of the system. But, memory_present() is for sparsemem, which basically implements pfn_to_page() and page_to_pfn(). The numa_memory_lookup_table[] is used for pfn_to_nid(), which is actually orthogonal to what sparsemem needs. > Can we kill numa_memory_lookup_table with this? Nope, we still need it for pfn_to_nid(). We could possibly replace the current implementation like this: #define pfn_to_nid(pfn) page_zone(__pfn_to_section(pfn)->section_mem_map[pfn])->zone_pgdat->node_id But, that might have a few performance implications :) There are certainly some options that sparsemem opens up here, and I hope that we explore them further as we move away from discontig. We could even do something like store the nid directly in the mem_section. But, as I said, that's an optimization that can come later. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-05-05 06:46 [from the cache] ©2003-2008 | |||||||||||||