Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
> 
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> 

yes with the patch below it seems useless. But it's also a good way
for all arch to use the same name for defining the start of the
memory.

>> IMHO the question is now, which method is the best one ?
> 
> My method should very slightly reduce the size of the kernel and have a
> very minor performance improvement. How measurable it is depends on how
> often page_to_pfn and pfn_to_page are called.
> 
>> the we probably need to get ride of the previous method and add yours
>> (but don't forget to modify arch such ARM which are currently using
>> ARCH_PFN_OFFSET).
>>
> 
> If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;

here is the patch I'm using, which is mainly yours.

-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0

The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0. Some archictectures, like ARM, use ARCH_PFN_OFFSET to
relax this requirement. This involves one more operation during
page/pfn conversions.

Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
This results in a slight gain on kernel code size.

---
 include/asm-generic/memory_model.h |    6 +++---
 mm/page_alloc.c                    |   15 +++++++++++----
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
  */
 #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 --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..ed6a40f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
 
 static void __init alloc_node_mem_map(struct pglist_data *pgdat)
 {
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+	struct page *map = pgdat->node_mem_map;
+
 	/* Skip empty nodes */
 	if (!pgdat->node_spanned_pages)
 		return;
 
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
 	/* ia64 gets its own node_mem_map, before this, without bootmem */
-	if (!pgdat->node_mem_map) {
+	if (!map) {
 		unsigned long size, start, end;
-		struct page *map;
 
 		/*
 		 * The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
 	 * With no DISCONTIG, the global mem_map is just set as node 0's
 	 */
 	if (pgdat == NODE_DATA(0))
-		mem_map = NODE_DATA(0)->node_mem_map;
+		/*
+		 * mem_map is assumed to be based at pfn 0 such that
+		 * 'pfn = page* - mem_map' is true. Adjust map
+		 * relative to node_mem_map to maintain this
+		 * relationship.
+		 */
+		mem_map = map - ARCH_PFN_OFFSET;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
-- 
1.4.0.g64e8

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/