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 --- kernel/sched_fair.c | 4 ++++ 1 file changed, 4 insertions(+) Index: tip/kernel/sched_fair.c =================================================================== --- tip.orig/kernel/sched_fair.c +++ tip/kernel/sched_fair.c @@ -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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/