Messages in this thread | | | Date | Thu, 5 Mar 2009 02:03:19 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 1/2] sched: don't rebalance if attached on NULL domain |
| |
On Thu, Mar 05, 2009 at 01:27:02AM +0100, Frederic Weisbecker wrote: > 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. > > This patch fixes it by checking if we are attached to the null domain before raising the softirq, > another possible fix would be to set the maximal possible JIFFIES value to rq->next_balance if we are > attached to the NULL domain. > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
And speacking about the function graph hang, Reported-by: Ingo Molnar <mingo@elte.hu>
| |