Re: [patch] slab: add memory hotplug support

[KAMEZAWA Hiroyuki]

On Tue, 2 Mar 2010 14:20:06 -0600 (CST)
Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> Not sure how this would sync with slab use during node bootstrap and
> shutdown. Kame-san?
> 
> Otherwise
> 
> Acked-by: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx>
> 

What this patch fixes ? Maybe I miss something...

At node hot-add

 * pgdat is allocated from other node (because we have no memory for "nid")
 * memmap for the first section (and possiby others) will be allocated from
   other nodes.
 * Once a section for the node is onlined, any memory can be allocated localy.

   (Allocating memory from local node requires some new implementation as
    bootmem allocater, we didn't that.)

 Before this patch, slab's control layer is allocated by cpuhotplug.
 So, at least keeping this order,
    memory online -> cpu online
 slab's control layer is allocated from local node.

 When node-hotadd is done in this order
    cpu online -> memory online
 kmalloc_node() will allocate memory from other node via fallback.

 After this patch, slab's control layer is allocated by memory hotplug.
 Then, in any order, slab's control will be allocated via fallback routine.

If this patch is an alternative fix for Andi's this logic
==
Index: linux-2.6.32-memhotadd/mm/slab.c
===================================================================
--- linux-2.6.32-memhotadd.orig/mm/slab.c
+++ linux-2.6.32-memhotadd/mm/slab.c
@@ -4093,6 +4093,9 @@ static void cache_reap(struct work_struc
 		 * we can do some work if the lock was obtained.
 		 */
 		l3 = searchp->nodelists[node];
+		/* Note node yet set up */
+		if (!l3)
+			break;
==
I'm not sure this really happens.

cache_reap() is for checking local node. The caller is set up by
CPU_ONLINE. searchp->nodelists[] is filled by CPU_PREPARE.

Then, cpu for the node should be onlined. (and it's done under proper mutex.)

I'm sorry if I miss something important. But how anyone cause this ?

Thanks,
-Kame



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/