Skip to contentSkip to conversation

remove zone_mem_map

PATCH In review KAMEZAWA Hiroyuki 3 participants 7 messages Feb 22, 2006

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 remove zone_mem_map

This patch removes zone_mem_map from zone.
By this, (generic) page_to_pfn and pfn_to_page can use the same logic. This modifies page_to_pfn implementation. Could anyone do performance test on NUMA ?

(ia64 is not affected by this because it doesn't use generic page_to_pfn.)

-- Kame

This patch removes zone_mem_map.

However pfn_to_page uses pgdat, page_to_pfn uses zone. page_to_pfn can use pgdat instead of zone, which is only one user of zone_mem_map. By modifing it, we can remove zone_mem_map.

include/asm-generic/memory_model.h +3 -3
Index: test/include/asm-generic/memory_model.h
===================================================================
@@ -47,9 +47,9 @@ extern unsigned long page_to_pfn(struct
 
 #define page_to_pfn(pg)			\
 ({	struct page *__pg = (pg);		\
-	struct zone *__zone = page_zone(__pg);	\
-	(unsigned long)(__pg - __zone->zone_mem_map) +	\
-	 __zone->zone_start_pfn;			\
+	struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg));	\
+	(unsigned long)(__pg - __pgdat->node_mem_map) +	\
+	 __pgdat->node_start_pfn;			\
 })
 
 #elif defined(CONFIG_SPARSEMEM)
include/linux/mmzone.h +0 -1
Index: test/include/linux/mmzone.h
===================================================================
@@ -225,7 +225,6 @@ struct zone {
 	 * Discontig memory support fields.
 	 */
 	struct pglist_data	*zone_pgdat;
-	struct page		*zone_mem_map;
 	/* zone_start_pfn == zone_start_paddr >> PAGE_SHIFT */
 	unsigned long		zone_start_pfn;
 
mm/page_alloc.c +2 -3
Index: test/mm/page_alloc.c
===================================================================
@@ -2117,7 +2117,6 @@ static __meminit void init_currently_emp
 	zone_wait_table_init(zone, size);
 	pgdat->nr_zones = zone_idx(zone) + 1;
 
-	zone->zone_mem_map = pfn_to_page(zone_start_pfn);
 	zone->zone_start_pfn = zone_start_pfn;
 
 	memmap_init(size, pgdat->node_id, zone_idx(zone), zone_start_pfn);
@@ -2844,8 +2843,8 @@ struct page *pfn_to_page(unsigned long p
 }
 unsigned long page_to_pfn(struct page *page)
 {
-	struct zone *zone = page_zone(page);
-	return (page - zone->zone_mem_map) + zone->zone_start_pfn;
+	struct pglist_data *pgdat = NODE_DATA(page_to_nid(page));
+	return (page - pgdat->node_mem_map) + pgdat->node_start_pfn;
 
 }
 #elif defined(CONFIG_SPARSEMEM)
include/asm-alpha/mmzone.h +1 -2
Index: test/include/asm-alpha/mmzone.h
===================================================================
@@ -83,8 +83,7 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p,
 	pte_t pte;                                                           \
 	unsigned long pfn;                                                   \
 									     \
-	pfn = ((unsigned long)((page)-page_zone(page)->zone_mem_map)) << 32; \
-	pfn += page_zone(page)->zone_start_pfn << 32;			     \
+	pfn = page_to_pfn(page) << 32; \
 	pte_val(pte) = pfn | pgprot_val(pgprot);			     \
 									     \
 	pte;								     \
#1 lore raw
Quoted 3 lines · KAMEZAWA Hiroyuki

This patch removes zone_mem_map from zone.
By this, (generic) page_to_pfn and pfn_to_page can use the same logic.

I assume this is dependent upon unify-pfn_to_page-*.patch?

Quoted 1 line

This modifies page_to_pfn implementation. Could anyone do performance test on NUMA ?

Do you expect there to be NUMA performance problems? If so, how do they arise and what sort of tests should be run?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#2 lore raw
Quoted 6 lines · Andrew Morton
Quoted 2 lines · KAMEZAWA Hiroyuki

This patch removes zone_mem_map from zone.
By this, (generic) page_to_pfn and pfn_to_page can use the same logic.

I assume this is dependent upon unify-pfn_to_page-*.patch?

yes. sorry for forgetting to write it.

Quoted 5 lines
Quoted 1 line

This modifies page_to_pfn implementation. Could anyone do performance test on NUMA ?

Do you expect there to be NUMA performance problems? If so, how do they arise and what sort of tests should be run?

I don't expect it. But when I posted this before (as RFC), some persons (Martin J. Bligh and Dave Hansen) had concerns about it.

I think the heaviest users of page_to_pfn() are the page allocator and mk_pte(page_to_pfn(page), hogehoge).

So, tests like "mmap -> touch all -> unmap" will be good test.

powerpc and ia64 is not a good test environment, because they don't use page_to_pfn() of generic DISCONTIG definitions.

other NUMAs (i386, x86_64 etc..) will be good.

Thanks,
-- Kame

#3 lore raw
In reply to KAMEZAWA Hiroyuki
Quoted 1 line · KAMEZAWA Hiroyuki

This patch removes zone_mem_map.

Note that IA64 does not seem to depend on zone_mem_map...

Quoted 5 lines

Index: test/include/asm-generic/memory_model.h
===================================================================

include/asm-generic/memory_model.h extern unsigned long page_to_pfn(struct · line 53

Quoted 10 lines
include/asm-generic/memory_model.h +3 -3
@@ -47,9 +47,9 @@ extern unsigned long page_to_pfn(struct
 
 #define page_to_pfn(pg)			\
 ({	struct page *__pg = (pg);		\
-	struct zone *__zone = page_zone(__pg);	\
-	(unsigned long)(__pg - __zone->zone_mem_map) +	\
-	 __zone->zone_start_pfn;			\
+	struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg));	\
+	(unsigned long)(__pg - __pgdat->node_mem_map) +	\
+	 __pgdat->node_start_pfn;			\
 })

NODE_DATA is an arch specific lookup, If it always is a table lookup then the performance will be comparable to page_zone because that also involves one table lookup.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#4 lore raw
Quoted 6 lines · Christoph Lameter
Quoted 1 line · KAMEZAWA Hiroyuki

This patch removes zone_mem_map.

Note that IA64 does not seem to depend on zone_mem_map...

Oh, yes. ia64 doesn't includes asm-generic/memory_model.h when DISCONTIGMEM.

Quoted 6 lines
Quoted 6 lines

Index: test/include/asm-generic/memory_model.h
===================================================================

include/asm-generic/memory_model.h +0 -0
@@ -47,9 +47,9 @@ extern unsigned long page_to_pfn(struct
 
Quoted 13 lines

include/asm-generic/memory_model.h extern unsigned long page_to_pfn(struct · line 53

Quoted 9 lines
include/asm-generic/memory_model.h +3 -3
 #define page_to_pfn(pg)			\
 ({	struct page *__pg = (pg);		\
-	struct zone *__zone = page_zone(__pg);	\
-	(unsigned long)(__pg - __zone->zone_mem_map) +	\
-	 __zone->zone_start_pfn;			\
+	struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg));	\
+	(unsigned long)(__pg - __pgdat->node_mem_map) +	\
+	 __pgdat->node_start_pfn;			\
 })

NODE_DATA is an arch specific lookup, If it always is a table lookup
then the performance will be comparable to page_zone because that also involves one table lookup.

There are several types of NODE_DATA definitions.
1. #define NODE_DATA(node) (&node_data[node]) alpha,arm,
2. #define NODE_DATA(node) (node_data[node]) i386,powerpc,x86_64,m32r
3. #define NODE_DATA(node) (&node_data[node]->pgdat) parisc,mips
4. #define NODE_DATA(node) (per-cpu-page has node_data[nid] pointer array) ia64

BTW, ia64 looks very special. Does it make sensible performance gain ?

-- Kame

#5 lore raw
Quoted 1 line · KAMEZAWA Hiroyuki

BTW, ia64 looks very special. Does it make sensible performance gain ?

Well yes, we actually have virtual mappings in kernel address space. F.e. The hotplug remove issues could be fixed there by remapping pages.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#6 lore raw
Quoted 6 lines · Christoph Lameter
Quoted 1 line · KAMEZAWA Hiroyuki

BTW, ia64 looks very special. Does it make sensible performance gain ?

Well yes, we actually have virtual mappings in kernel address space. F.e. The hotplug remove issues could be fixed there by remapping pages.

Ah, if we place node_data[i](array of pointer to pgdat) in region 7, there is no trouble ?
(maybe zone_table[] should be also..)

-- Kame