On Mon, 29 Jan 2007, Oleg Nesterov wrote:
> > But we could delay CPU_DOWN in the handler for the slab until we know that
> > the cache_reaper is no longer running?
>
> Hmm... I don't undestand this. We can delay CPU_DOWN if we cancel cache_reaper
> like you did in the previous patch. Did you mean this? If yes - then yes :)
Yes sure.
> Worse, we can have 2 handlers running in parallel on the same CPU. But this
> is fixed by your previous patch, I believe.
Good.
Here is the patch against 2.6.20-rc6-mm2. CPU_DOWN_PREPARE and
CPU_DOWN_FAILED somehow vanished in mm?
Shutdown cache_reaper when cpu goes down
Shutdown the cache_reaper in slab.c if the cpu is brought down
and set the cache_reap.func to NULL. Otherwise hotplug shuts
down the reaper for good.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc6-mm1/mm/slab.c
===================================================================
--- linux-2.6.20-rc6-mm1.orig/mm/slab.c 2007-01-29 14:18:37.000000000 -0600
+++ linux-2.6.20-rc6-mm1/mm/slab.c 2007-01-29 14:21:18.119155877 -0600
@@ -1271,6 +1271,17 @@ static int __cpuinit cpuup_callback(stru
start_cpu_timer(cpu);
break;
#ifdef CONFIG_HOTPLUG_CPU
+ case CPU_DOWN_PREPARE:
+ /* Shutdown cache reaper */
+ cancel_rearming_delayed_work(&per_cpu(reap_work, cpu));
+ per_cpu(reap_work, cpu).work.func = NULL;
+
+ mutex_lock(&cache_chain_mutex);
+ break;
+ case CPU_DOWN_FAILED:
+ mutex_unlock(&cache_chain_mutex);
+ start_cpu_timer(cpu);
+ break;
case CPU_DEAD:
/*
* Even if all the cpus of a node are down, we don't free the
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
