Re: 2.6.17-mm1

[mel@skynet.ie (Mel Gorman)]

On (26/06/06 15:49), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> > 
> >> Mel Gorman wrote:
> > 
> >>>>> Not all arches will use init_bootmem(). Arm for example uses
> >>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
> >>>>>
> >>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> >>>> page number that has physical memory. I don't see why we couldn't
> >>>> useit to correctly initialise the memory system...
> >>>
> >>> Architectures will not always have a known fixed start of physical
> >>> memory. On IA64 at least, they initialise memory as if it starts at 0
> >>> but on my one test machine, the beginning part is always a memory hole.
> >>
> >> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> >> change...
> >>
> > 
> > The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> > you alter those two initialisation functions. Currently it is used to
> > offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> > free_area_init() and init_bootmem(), it changes to altering the value of
> > NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> > particular way. 
> 
> well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
> with free_area_init() and init_bootmem() ?

I don't know for sure and for that reason alone, I'd rather not change
the meaning of ARCH_PFN_OFFSET as part of a "fix".

> If so, there is a bug since
> NODE_DATA(0)->node_start_pfn is not setup correctly...
> 
> > I think we should just fix the problem at hand now for which two simple
> > patches have been posted and consider making further changes to
> > free_area_init() and init_bootmem() as a separate issue.
> > 
> 
> I agree this is a separate issue. We should resolve it in a different thread.
> Mind to start a new one that involve people who can shed some light here ?
> 

Lets close this out first and then figure out where to go next.  The following
patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
!= 0 and documents what ARCH_PFN_OFFSET is for.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h	2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h	2006-06-26 15:22:19.000000000 +0100
@@ -6,6 +6,20 @@
 
 #if defined(CONFIG_FLATMEM)
 
+/*
+ * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
+ * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
+ * represents the first physical page frame in the system. This is not
+ * always the case as an architecture may start physical memory at 3GB
+ * for example. Rather than allocating an empty mem_map to represent
+ * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
+ * NODE_DATA(0)->node_mem_map such that;
+ *
+ * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
+ *
+ * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
+ * depending on how memory is initialised, this is not always the case.
+ */
 #ifndef ARCH_PFN_OFFSET
 #define ARCH_PFN_OFFSET		(0UL)
 #endif
@@ -28,9 +42,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm2-clean/mm/page_alloc.c	2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c	2006-06-26 15:11:29.000000000 +0100
@@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		map -= ARCH_PFN_OFFSET;
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
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/