linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: keith mannthey <kmannth@us.ibm.com>
To: lhms-devel <lhms-devel@lists.sourceforge.net>
Cc: linux-mm <linux-mm@kvack.org>,
	ak@suse.de, dave hansen <haveblue@us.ibm.com>,
	kame <kamezawa.hiroyu@jp.fujitsu.com>
Subject: [RFC] Patch [1/4] x86_64 sparsmem add- save nodes_add data for later
Date: Fri, 23 Jun 2006 19:05:15 -0700	[thread overview]
Message-ID: <1151114715.7094.49.camel@keithlap> (raw)
In-Reply-To: <1151082833.10877.13.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hello All,
  The following patch reserves the nodes_add data for use later.  It
retains the bulk of the hotadd_precent defense that is built into the
SRAT code. It is a little subtle but it gets the job done.  

  The code saves off the hot-add area ranges without extending the end
of memory.  It then creates arch_find_node which will be use in the next
patch.  

 arch_find_node is passed a memory range and it looks for a nodes_add
area it fits into.   If no area is found it returns 0.

 With this and the other 3 patches I can do SPARSEMEM x86_64 hot-add on
my hardware. (the first 2 patches are one I consider real the other 2
are more to point out issues)

 It is built against 2.6.17-mm1 x86_64 and the current memory_hotplug
work but should apply on any current srat.c

Signed-off-by:  Keith Mannthey <kmannth@us.ibm.com>


[-- Attachment #2: patch-2.6.17-mm1-save_nodes_add --]
[-- Type: text/x-patch, Size: 2650 bytes --]

diff -urN linux-2.6.17-mm1-orig/arch/x86_64/mm/srat.c linux-2.6.17-mm1/arch/x86_64/mm/srat.c
--- linux-2.6.17-mm1-orig/arch/x86_64/mm/srat.c	2006-06-23 16:12:00.000000000 -0400
+++ linux-2.6.17-mm1/arch/x86_64/mm/srat.c	2006-06-23 18:43:03.000000000 -0400
@@ -34,9 +34,6 @@
 static struct bootnode nodes_add[MAX_NUMNODES] __initdata;
 static int found_add_area __initdata;
 int hotadd_percent __initdata = 0;
-#ifndef RESERVE_HOTADD
-#define hotadd_percent 0	/* Ignore all settings */
-#endif
 
 /* Too small nodes confuse the VM badly. Usually they result
    from BIOS bugs. */
@@ -199,9 +196,9 @@
 	allocated += mem;
 	return 1;
 }
-
+#endif
 /*
- * It is fine to add this area to the nodes data it will be used later
+ * It is fine to add this area to the nodes_add data it will be used later
  * This code supports one contigious hot add area per node.
  */
 static int reserve_hotadd(int node, unsigned long start, unsigned long end)
@@ -227,15 +224,14 @@
 		printk(KERN_ERR "SRAT: Hotplug area has existing memory\n");
 		return -1;
 	}
-
+#ifdef RESERVE_HOTADD
 	if (!hotadd_enough_memory(&nodes_add[node]))  {
 		printk(KERN_ERR "SRAT: Hotplug area too large\n");
 		return -1;
 	}
-
+#endif 
 	/* Looks good */
 
- 	found_add_area = 1;
 	if (nd->start == nd->end) {
  		nd->start = start;
  		nd->end = end;
@@ -253,14 +249,16 @@
 			printk(KERN_ERR "SRAT: Hotplug zone not continuous. Partly ignored\n");
  	}
 
- 	if ((nd->end >> PAGE_SHIFT) > end_pfn)
- 		end_pfn = nd->end >> PAGE_SHIFT;
-
 	if (changed)
 	 	printk(KERN_INFO "SRAT: hot plug zone found %Lx - %Lx\n", nd->start, nd->end);
+#ifdef RESERVE_HOTADD	
+ 	found_add_area = 1;
+	if ((nd->end >> PAGE_SHIFT) > end_pfn)
+ 		end_pfn = nd->end >> PAGE_SHIFT;
 	return 0;
+#endif 
+	return -1;
 }
-#endif
 
 /* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
 void __init
@@ -318,7 +316,6 @@
 	printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
 	       nd->start, nd->end);
 
-#ifdef RESERVE_HOTADD
  	if (ma->flags.hot_pluggable && reserve_hotadd(node, start, end) < 0) {
 		/* Ignore hotadd region. Undo damage */
 		printk(KERN_NOTICE "SRAT: Hotplug region ignored\n");
@@ -326,7 +323,6 @@
 		if ((nd->start | nd->end) == 0)
 			node_clear(node, nodes_parsed);
 	}
-#endif
 }
 
 /* Sanity check to catch more bad SRATs (they are amazingly common).
@@ -450,3 +446,14 @@
 }
 
 EXPORT_SYMBOL(__node_distance);
+
+int arch_find_node(unsigned long start, unsigned long size) {
+	int i, ret = 0;
+	unsigned long end = start+size;
+
+	for_each_node(i){
+		if (nodes_add[i].start <= start && nodes_add[i].end >= end)
+			ret = i;
+	}
+	return ret;
+}

      parent reply	other threads:[~2006-06-24  2:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21  5:43 [RFC] patch [1/1] x86_64 numa aware sparsemem add_memory functinality keith mannthey
2006-06-21  6:06 ` [Lhms-devel] " KAMEZAWA Hiroyuki
2006-06-21  6:25   ` keith mannthey
2006-06-21  6:37     ` KAMEZAWA Hiroyuki
2006-06-21  6:31   ` Yasunori Goto
2006-06-23 17:13 ` Dave Hansen
2006-06-23 17:57   ` [Lhms-devel] " keith mannthey
2006-06-24  2:05   ` keith mannthey [this message]

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=1151114715.7094.49.camel@keithlap \
    --to=kmannth@us.ibm.com \
    --cc=ak@suse.de \
    --cc=haveblue@us.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-mm@kvack.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox