Re: slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems

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 <clameter@xxxxxxx>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: BUG_ON(!cpus_equal(cpumask, tmp));
    ... is that the underlying cpu shutdown code is not clearing out all ... the process of sending an IPI. ... Below is a patch to 2.6.5-rc3 which implements this idea, ...
    (Linux-Kernel)
  • Re: slab: start_cpu_timer/cache_reap CONFIG_HOTPLUG_CPU problems
    ... anymore, right? ... Which brings us to this form of the patch: ... Shutdown the cache_reaper in slab.c if the cpu is brought down ...
    (Linux-Kernel)
  • Re: RT patch acceptance (scheduler)
    ... > lock up the CPU in IRQ mode for human-perceptible time, ... For non-DMA IDE access data copies are CPU driven ... which can create tons of latency problems for that case. ... I suggest that you read the patch for the answer to softirq ...
    (Linux-Kernel)
  • Re: better wake-balancing: respin
    ... >>I guess I missed the objection for dropping the patch. ... correlation between the CPU the interrupt arrives on and the CPU the ... There is no point in immediate balancing either: ... If this patch hurts other workloads (and please ...
    (Linux-Kernel)
  • [PATCH] v5 Teach RCU that idle task is not quiscent state at boot
    ... The boot CPU runs in the context of its idle thread during boot-up. ... RCU to prematurely end grace periods during this time. ... This patch changes the rcutree.c and rcuclassic.c rcu_check_callbacks ...
    (Linux-Kernel)