![]() | |||||||||||
Messages in this thread |
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? > > >>@@ -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)? > Can we kill numa_memory_lookup_table with this? This table basically is part of the DISCONTIGMEM implementation and used lightly by SPARSEMEM. In the i386 port we have already pushd that out into a discontigmem implementation of memory_present. That is a logical next step in this port and I've got some of it already done. That should sit nicely on this lot. I'll work on this one. -apw - 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 14:10 [from the cache] ©2003-2008 | |||||||||||