Re: [patch] slab: add memory hotplug support

KAMEZAWA Hiroyuki
2010-03-03T01:32:21Z

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

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

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