On Thu, 5 Mar 2009, Frederic Weisbecker wrote: > > sched: don't rebalance if attached on NULL domain > > Impact: fix function graph trace hang / drop pointless softirq on UP > > While debugging a function graph trace hang on an old PII, I saw > that it consumed most of its time on the timer interrupt. And > the domain rebalancing softirq was the most concerned. > > The timer interrupt calls trigger_load_balance() which will > decide if it is worth to schedule a rebalancing softirq. > > In case of builtin UP kernel, no problem arises because there is > no domain question. > > In case of builtin SMP kernel running on an SMP box, still no > problem, the softirq will be raised each time we reach the > next_balance time. > > In case of builtin SMP kernel running on a UP box (most distros > provide default SMP kernels, whatever the box you have), then > the CPU is attached to the NULL sched domain. So a kind of > unexpected behaviour happen: > > trigger_load_balance() -> raises the rebalancing softirq later > on softirq: run_rebalance_domains() -> rebalance_domains() where > the for_each_domain(cpu, sd) is not taken because of the NULL > domain we are attached at. Which means rq->next_balance is never > updated. So on the next timer tick, we will enter > trigger_load_balance() which will always reschedule() the > rebalacing softirq: > > if (time_after_eq(jiffies, rq->next_balance)) > raise_softirq(SCHED_SOFTIRQ); > > So for each tick, we process this pointless softirq. Nice catch! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|