From: tip-bot for Amit K. Arora on
Commit-ID: 54e88fad223c4e1d94289611a90c7fe3ebe5631b
Gitweb: http://git.kernel.org/tip/54e88fad223c4e1d94289611a90c7fe3ebe5631b
Author: Amit K. Arora <aarora(a)linux.vnet.ibm.com>
AuthorDate: Tue, 25 May 2010 18:53:46 +0530
Committer: Ingo Molnar <mingo(a)elte.hu>
CommitDate: Mon, 31 May 2010 08:37:44 +0200

sched: Make sure timers have migrated before killing the migration_thread

Problem: In a stress test where some heavy tests were running along with
regular CPU offlining and onlining, a hang was observed. The system seems
to be hung at a point where migration_call() tries to kill the
migration_thread of the dying CPU, which just got moved to the current
CPU. This migration thread does not get a chance to run (and die) since
rt_throttled is set to 1 on current, and it doesn't get cleared as the
hrtimer which is supposed to reset the rt bandwidth
(sched_rt_period_timer) is tied to the CPU which we just marked dead!

Solution: This patch pushes the killing of migration thread to
"CPU_POST_DEAD" event. By then all the timers (including
sched_rt_period_timer) should have got migrated (along with other
callbacks).

Signed-off-by: Amit Arora <aarora(a)in.ibm.com>
Signed-off-by: Gautham R Shenoy <ego(a)in.ibm.com>
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
LKML-Reference: <20100525132346.GA14986(a)amitarora.in.ibm.com>
Signed-off-by: Ingo Molnar <mingo(a)elte.hu>
---
kernel/stop_machine.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index b4e7431..70f8d90 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -321,7 +321,7 @@ static int __cpuinit cpu_stop_cpu_callback(struct notifier_block *nfb,

#ifdef CONFIG_HOTPLUG_CPU
case CPU_UP_CANCELED:
- case CPU_DEAD:
+ case CPU_POST_DEAD:
{
struct cpu_stop_work *work;

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