Hi all,
Since observed dead lock problem in sched run_rebalance_domains of
kernel 2.6.21.7, we just disabling SCHED_SOFTIRQ to trigger
run_rebalance_domains as one work around. The patch is as below:
--- kernel/sched.c 2012-06-29 23:17:34.000000000 +0800
+++ kernel-new/sched.c 2012-09-12 17:27:28.000000000 +0800
@@ -2940,7 +2940,7 @@ static void update_load(struct rq *this_
* Balancing parameters are set up in arch_init_sched_domains.
*/
static DEFINE_SPINLOCK(balancing);
-
+#if 0
static void run_rebalance_domains(struct softirq_action *h)
{
int this_cpu = smp_processor_id(), balance = 1;
@@ -3001,6 +3001,7 @@ out:
}
this_rq->next_balance = next_balance;
}
+#endif
#else
/*
* on UP we do not need to balance between CPUs:
@@ -3230,9 +3231,11 @@ void scheduler_tick(void)
task_running_tick(rq, p);
#ifdef CONFIG_SMP
update_load(rq);
+#if 0
if (time_after_eq(jiffies, rq->next_balance))
raise_softirq(SCHED_SOFTIRQ);
#endif
+#endif
}
#if defined(CONFIG_PREEMPT) && defined(CONFIG_DEBUG_PREEMPT)
@@ -6766,9 +6769,11 @@ void __init sched_init(void)
set_load_weight(&init_task);
+#if 0
#ifdef CONFIG_SMP
open_softirq(SCHED_SOFTIRQ, run_rebalance_domains, NULL);
#endif
+#endif
#ifdef CONFIG_RT_MUTEXES
plist_head_init(&init_task.pi_waiters, &init_task.pi_lock);
Our experimentations and simulations that we have conducted so far did
not indicated any performance decrease due to disable re-balancing.
Since our system isn't always busy, the idle_balance can work well for
processes load balance instead of run_rebalance_domains. However my
concern is if there is any side effects which I didn't consider.
Thanks,
Xiong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
