Skip to contentSkip to conversation

fix CONFIG_DISCONTIGMEM and CONFIG_VIRTUAL_MEMMAP

PATCH In review Jesse Barnes 2 participants 2 messages Sep 5, 2004 – Sep 6, 2004

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 fix CONFIG_DISCONTIGMEM and CONFIG_VIRTUAL_MEMMAP

Looks like the patch that fixed Ian's problem introduced an ugly warning. Maybe we could just switch to requiring CONFIG_DISCONTIGMEM and CONFIG_VIRTUAL_MEMMAP for ia64 in general? That would let us kill a lot of code and only have one code path, etc. Benchmarks have shown that the overhead of CONFIG_DISCONTIGMEM is very difficult to measure (if you look at the code, the only added overhead in any fast path is an additional pointer dereference in alloc_pages). CONFIG_VIRTUAL_MEMMAP is a little more expensive iirc, but still difficult to measure.

Jesse

===== include/asm-ia64/page.h 1.27 vs edited =====

include/asm-ia64/page.h +5 -5
@@ -89,11 +89,11 @@
 #  define pfn_valid(pfn)       (((pfn) < max_mapnr) && ia64_pfn_valid(pfn))
 #  define page_to_pfn(page)    ((unsigned long) (page - vmem_map))
 #  define pfn_to_page(pfn)     (vmem_map + (pfn))
-# endif
-#else /* !CONFIG_VIRTUAL_MEM_MAP */
-#define pfn_valid(pfn)		(((pfn) < max_mapnr) && ia64_pfn_valid(pfn))
-#define page_to_pfn(page)	((unsigned long) (page - mem_map))
-#define pfn_to_page(pfn)	(mem_map + (pfn))
+# else /* !CONFIG_VIRTUAL_MEM_MAP */
+#  define pfn_valid(pfn)		(((pfn) < max_mapnr) && ia64_pfn_valid(pfn))
+#  define page_to_pfn(page)	((unsigned long) (page - mem_map))
+#  define pfn_to_page(pfn)	(mem_map + (pfn))
+# endif /* CONFIG_VIRTUAL_MEMMAP */
 #endif /* CONFIG_DISCONTIGMEM */
 
 #define page_to_phys(page)	(page_to_pfn(page) << PAGE_SHIFT)
#1 lore raw
Quoted 8 lines · Jesse Barnes

Looks like the patch that fixed Ian's problem introduced an ugly warning. Maybe we could just switch to requiring CONFIG_DISCONTIGMEM and CONFIG_VIRTUAL_MEMMAP for ia64 in general? That would let us kill a lot of code and only have one code path, etc. Benchmarks have shown that the overhead of CONFIG_DISCONTIGMEM is very difficult to measure (if you look at the code, the only added overhead in any fast path is an additional pointer dereference in alloc_pages). CONFIG_VIRTUAL_MEMMAP is a little more expensive iirc, but still difficult to measure.

Guilty as charged, I only checked it on my machine.

If performance isn't an issue [*], for mine, combining the the two seems like the most logical thing to do to me, as it is only causing confusion with the two being apart. Setting myself the simple goal of running with discontig and virtual mem map without NUMA, the diffstat of the patch looks like

 Makefile                     |    2
 arch/ia64/Kconfig            |    4
 arch/ia64/mm/discontig.c     |  180 ++-----------------------------------------
 arch/ia64/mm/numa.c          |  171 ++++++++++++++++++++++++++++++++++++++++
 include/asm-ia64/meminit.h   |    2
 include/asm-ia64/processor.h |    4
 6 files changed, 189 insertions(+), 174 deletions(-)

Most of that is copy-paste moving of a few things from discontig.c to in numa.c. My point is that it probably isn't too hard (but I guess that's probably not news).

-i

[*] I'm always happy to run any benchmarks you want on the machines we have.