[RFC] Patch [3/4] x86_64 sparsmem add - acpi added pages are not reserved?

[RFC] Patch [3/4] x86_64 sparsmem add - acpi added pages are not reserved?

[keith mannthey]

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

I got everything in place to do a working hot-add with 2.6.17-mm1 and I
ran into another trouble spot.  

I added the memory just fine(new device is sysfs) but when I went to on-
line them in sysfs I tripped over the little section of code this patch
comments out.  I was get device not ready messages on my console and the
comment printed in my kernel log.   

  With hacked acpi drivers outside of -mm I don't run into the problem
so I think something is a little off in -mm. 

  The code is expecting the added but not on-lined code to be marked
reserved. This isn't happening for my ACPI hot-add on x86_64. I am not
sure who in this call path needs to reserve the pages or if the check
for reserve is a valid with this new hot-add code.    

Any ideas?

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

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

diff -urN linux-2.6.17-mm1-orig/drivers/base/memory.c linux-2.6.17-mm1/drivers/base/memory.c
--- linux-2.6.17-mm1-orig/drivers/base/memory.c	2006-06-23 16:12:01.000000000 -0400
+++ linux-2.6.17-mm1/drivers/base/memory.c	2006-06-23 20:04:04.000000000 -0400
@@ -163,9 +163,9 @@
 	/*
 	 * The probe routines leave the pages reserved, just
 	 * as the bootmem code does.  Make sure they're still
-	 * that way.
+	 * that way.  UNLESS you do real hot add? 
 	 */
-	if (action == MEM_ONLINE) {
+/*	if (action == MEM_ONLINE) {
 		for (i = 0; i < PAGES_PER_SECTION; i++) {
 			if (PageReserved(first_page+i))
 				continue;
@@ -176,6 +176,7 @@
 			return -EBUSY;
 		}
 	}
+*/
 
 	switch (action) {
 		case MEM_ONLINE:

Re: [RFC] Patch [3/4] x86_64 sparsmem add - acpi added pages are not reserved?

[KAMEZAWA Hiroyuki]

On Fri, 23 Jun 2006 19:06:03 -0700
keith mannthey <kmannth@us.ibm.com> wrote:

>   The code is expecting the added but not on-lined code to be marked
> reserved. This isn't happening for my ACPI hot-add on x86_64. I am not
> sure who in this call path needs to reserve the pages or if the check
> for reserve is a valid with this new hot-add code.    
> 
> Any ideas?
> 
> Signed-off-by:  Keith Mannthey <kmannth@us.ibm.com>
> 
/*	if (action == MEM_ONLINE) {
 		for (i = 0; i < PAGES_PER_SECTION; i++) {
 			if (PageReserved(first_page+i))
 				continue;
@@ -176,6 +176,7 @@
 			return -EBUSY;
 		}
 	}
+*/
Pages are marked as Reserved before onlined. Then, all pages in the area
should be reserved.(and sparsemem allocates SECTION_SIZE aligned memmap.)
(see __add_zone() -> memmap_init_zone().)
newly initialized memmap are marked as reserved. 
Plz confirm your "currently unused memmap" is properly marked as reserved.

It's important to find "why" before doing this kind of workaround.

Hmm... at first, could you show your /proc/iomem before and after
hot-add event ?

Thanks,
-Kame

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