[patch 1/2] sched: check for prev_cpu == this_cpu in wake_affine()
From: Suresh Siddha
Date: Fri Mar 05 2010 - 13:45:32 EST
On a single cpu system with SMT, in the scenario of one SMT thread being
idle with another SMT thread running a task and doing a non sync wakeup of
another task, we see (from the traces) that the woken up task ends up running
on the busy thread instead of the idle thread. Idle balancing that comes
in little bit later is fixing the scernaio.
But fixing this wake balance and running the woken up task directly on the
idle SMT thread improved the performance (phoronix 7zip compression workload)
by ~9% on an atom platform.
During the process wakeup, select_task_rq_fair() and wake_affine() makes
the decision to wakeup the task either on the previous cpu that the task
ran or the cpu that the task is currently woken up.
select_task_rq_fair() also goes through to see if there are any idle siblings
for the cpu that the task is woken up on. This is to ensure that we select
any idle sibling rather than choose a busy cpu.
In the above load scenario, it so happens that the prev_cpu (that the
task ran before) and this_cpu (where it is woken up currently) are the same. And
in this case, it looks like wake_affine() returns 0 and ultimately not selecting
the idle sibling chosen by select_idle_sibling() in select_task_rq_fair().
Further down the path of select_task_rq_fair(), we ultimately select
the currently running cpu (busy SMT thread instead of the idle SMT thread).
Check for prev_cpu == this_cpu in wake_affine() and no need to do
any fancy stuff(and ultimately taking wrong decisions) in this case.
Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
kernel/sched_fair.c | 4 ++++
1 file changed, 4 insertions(+)
@@ -1252,6 +1252,10 @@ static int wake_affine(struct sched_doma
idx = sd->wake_idx;
this_cpu = smp_processor_id();
prev_cpu = task_cpu(p);
+ if (prev_cpu == this_cpu)
+ return 1;
load = source_load(prev_cpu, idx);
this_load = target_load(this_cpu, idx);
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/