From: Yinghai Lu <yhlu.kernel@gmail.com>
To: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [PATCH] x86: 32bit numa increase max_elements to 1024
Date: Sat, 31 May 2008 22:51:51 -0700 [thread overview]
Message-ID: <200805312251.52297.yhlu.kernel@gmail.com> (raw)
In-Reply-To: <200805291625.56942.yhlu.kernel@gmail.com>
so every element will repsent to 64M instead of 256M.
AMD opteron later based could have HW memory hole remapping. so could have
[0, 8g + 64M) on node0. reduce element size to 64M could keep that on node 0
later need to use find_e820_area to allocate memory_node_map like 64bit.
but need to move memory_present out of populate_mem_map...
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
diff --git a/arch/x86/mm/discontig_32.c b/arch/x86/mm/discontig_32.c
index 0c1a1bf..0ea4854 100644
--- a/arch/x86/mm/discontig_32.c
+++ b/arch/x86/mm/discontig_32.c
@@ -59,14 +59,14 @@ unsigned long node_end_pfn[MAX_NUMNODES] __read_mostly;
/*
* 4) physnode_map - the mapping between a pfn and owning node
* physnode_map keeps track of the physical memory layout of a generic
- * numa node on a 256Mb break (each element of the array will
- * represent 256Mb of memory and will be marked by the node id. so,
+ * numa node on a 64Mb break (each element of the array will
+ * represent 64Mb of memory and will be marked by the node id. so,
* if the first gig is on node 0, and the second gig is on node 1
* physnode_map will contain:
*
- * physnode_map[0-3] = 0;
- * physnode_map[4-7] = 1;
- * physnode_map[8- ] = -1;
+ * physnode_map[0-15] = 0;
+ * physnode_map[16-31] = 1;
+ * physnode_map[32- ] = -1;
*/
s8 physnode_map[MAX_ELEMENTS] __read_mostly = { [0 ... (MAX_ELEMENTS - 1)] = -1};
EXPORT_SYMBOL(physnode_map);
@@ -81,9 +81,9 @@ void memory_present(int nid, unsigned long start, unsigned long end)
printk(KERN_DEBUG " ");
for (pfn = start; pfn < end; pfn += PAGES_PER_ELEMENT) {
physnode_map[pfn / PAGES_PER_ELEMENT] = nid;
- printk("%ld ", pfn);
+ printk(KERN_CONT "%ld ", pfn);
}
- printk("\n");
+ printk(KERN_CONT "\n");
}
unsigned long node_memmap_size_bytes(int nid, unsigned long start_pfn,
diff --git a/include/asm-x86/mmzone_32.h b/include/asm-x86/mmzone_32.h
index faef751..ab00128 100644
--- a/include/asm-x86/mmzone_32.h
+++ b/include/asm-x86/mmzone_32.h
@@ -51,14 +51,14 @@ extern int early_pfn_to_nid(unsigned long pfn);
/*
* generic node memory support, the following assumptions apply:
*
- * 1) memory comes in 256Mb contigious chunks which are either present or not
+ * 1) memory comes in 64Mb contigious chunks which are either present or not
* 2) we will not have more than 64Gb in total
*
* for now assume that 64Gb is max amount of RAM for whole system
* 64Gb / 4096bytes/page = 16777216 pages
*/
#define MAX_NR_PAGES 16777216
-#define MAX_ELEMENTS 256
+#define MAX_ELEMENTS 1024
#define PAGES_PER_ELEMENT (MAX_NR_PAGES/MAX_ELEMENTS)
extern s8 physnode_map[];
next prev parent reply other threads:[~2008-06-01 5:57 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-11 7:30 [PATCH] x86: make e820.c to have common functions Yinghai Lu
2008-05-13 13:05 ` Ingo Molnar
2008-05-13 17:35 ` Yinghai Lu
2008-05-18 8:18 ` [PATCH] x86: extend e820 ealy_res support 32bit Yinghai Lu
2008-05-21 3:10 ` [PATCH] x86: move e820_mark_nosave_regions to e820.c Yinghai Lu
2008-05-22 1:40 ` [PATCH] x86: extend e820 ealy_res support 32bit - fix Yinghai Lu
2008-05-22 10:12 ` Jeremy Fitzhardinge
2008-05-22 17:58 ` Yinghai Lu
2008-05-22 22:20 ` [PATCH] x86: extend e820 ealy_res support 32bit - fix v2 Yinghai Lu
2008-05-23 23:08 ` Yinghai Lu
2008-05-23 23:32 ` Jeremy Fitzhardinge
2008-05-23 23:38 ` Jeremy Fitzhardinge
2008-05-24 0:01 ` Yinghai Lu
2008-05-24 0:09 ` Yinghai Lu
2008-05-24 8:54 ` Jeremy Fitzhardinge
2008-05-24 9:49 ` [PATCH] xen: boot via i386_start_kernel to get early reservations Jeremy Fitzhardinge
2008-05-24 22:04 ` Yinghai Lu
2008-05-24 19:57 ` [PATCH] x86: extend e820 ealy_res support 32bit - fix v2 Yinghai Lu
2008-05-25 17:00 ` [PATCH] x86: extend e820 ealy_res support 32bit - fix #2 Yinghai Lu
2008-05-27 15:44 ` Thomas Gleixner
2008-05-27 20:37 ` Jeremy Fitzhardinge
2008-05-27 20:58 ` Thomas Gleixner
2008-05-27 21:06 ` Jeremy Fitzhardinge
2008-05-27 21:06 ` Yinghai Lu
2008-05-27 21:22 ` Jeremy Fitzhardinge
2008-05-27 21:35 ` Yinghai Lu
2008-05-27 21:47 ` Jeremy Fitzhardinge
2008-05-27 22:52 ` Yinghai Lu
2008-05-28 10:01 ` Jeremy Fitzhardinge
2008-05-28 20:48 ` Yinghai Lu
2008-05-28 21:24 ` Jeremy Fitzhardinge
2008-05-29 13:37 ` Jeremy Fitzhardinge
2008-05-29 18:41 ` Yinghai Lu
2008-05-29 18:58 ` H. Peter Anvin
2008-05-29 18:52 ` Yinghai Lu
2008-05-29 19:14 ` Yinghai Lu
2008-05-30 15:50 ` Jeremy Fitzhardinge
2008-05-29 19:56 ` [PATCH] x86: extend e820 early_res support 32bit -fix #3 Yinghai Lu
2008-05-29 19:57 ` [PATCH] x86: extend e820 early_res support 32bit -fix #4 Yinghai Lu
2008-05-29 19:58 ` [PATCH] x86: extend e820 early_res support 32bit -fix #5 Yinghai Lu
2008-05-29 23:25 ` [PATCH] x86: 32bit numa srat fix early_ioremap leak Yinghai Lu
2008-05-31 8:01 ` Ingo Molnar
2008-06-01 5:51 ` Yinghai Lu [this message]
2008-06-01 5:52 ` [PATCH] x86: change propagate_e820_map back to find_max_pfn -32bit Yinghai Lu
2008-06-01 5:53 ` [PATCH] x86: set node_remap_size[0] in fallback path Yinghai Lu
2008-06-01 5:56 ` [PATCH] x86: numa_32 print out debug info all kva Yinghai Lu
2008-06-01 20:15 ` [PATCH] x86: numa_32 print out debug info all kva v2 Yinghai Lu
2008-06-03 2:16 ` [PATCH] x86: change propagate_e820_map back to find_max_pfn -32bit -v2 Yinghai Lu
2008-06-02 4:06 ` [PATCH] x86: numa_32 avoid clash between ramdisk and kva Yinghai Lu
2008-06-02 6:53 ` [PATCH] x86: cleanup max_pfn_mapped usage - 32bit Yinghai Lu
2008-06-02 6:55 ` [PATCH] x86: cleanup max_pfn_mapped usage - 64bit Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805312251.52297.yhlu.kernel@gmail.com \
--to=yhlu.kernel@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.