[2/3] add memory present for ppc64

[2/3] add memory present for ppc64

[Andy Whitcroft]

Provide hooks for PPC64 to allow memory models to be informed
of installed memory areas.  This allows SPARSEMEM to instantiate
mem_map for the populated areas.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
---
 Kconfig   |    4 ++--
 mm/numa.c |    3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

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
 
 # Some NUMA nodes have memory ranges that span
 # other nodes.  Even though a pfn is valid and
diff -X /home/apw/brief/lib/vdiff.excl -rupN reference/arch/ppc64/mm/numa.c current/arch/ppc64/mm/numa.c
--- reference/arch/ppc64/mm/numa.c	2005-04-11 19:33:15.000000000 +0100
+++ current/arch/ppc64/mm/numa.c	2005-05-04 20:54:50.000000000 +0100
@@ -440,6 +440,8 @@ new_range:
 		for (i = start ; i < (start+size); i += MEMORY_INCREMENT)
 			numa_memory_lookup_table[i >> MEMORY_INCREMENT_SHIFT] =
 				numa_domain;
+		memory_present(numa_domain, start >> PAGE_SHIFT,
+						(start + size) >> PAGE_SHIFT);
 
 		if (--ranges)
 			goto new_range;
@@ -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);
 }
 
 static void __init dump_numa_topology(void)

Re: [2/3] add memory present for ppc64

[Olof Johansson]

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?


-Olof

Re: [2/3] add memory present for ppc64

[Dave Hansen]

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

Re: [2/3] add memory present for ppc64

[Andy Whitcroft]

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