On Thu, 08 May 2014 22:20:25 -0400 Rik van Riel <r...@redhat.com> wrote:
> Looks like SD_BALANCE_WAKE is not gotten from the sd flags at > all, but passed into select_task_rq by try_to_wake_up, as a > hard coded sd_flags argument. > Should we do that, if SD_WAKE_BALANCE is not set for any sched domain? I answered my own question. The sd_flag SD_WAKE_BALANCE simply means "this is a wakeup of a previously existing task, please place it properly". However, it appears that the current code will fall back to the large loop with select_idlest_group and friends, if prev_cpu and cpu are not part of the same SD_WAKE_AFFINE sched domain. That is a bug... ---8<--- Subject: sched: wake up task on prev_cpu if not in SD_WAKE_AFFINE domain with cpu If prev_cpu and cpu are not part of the same SD_WAKE_AFFINE domain, the current code will fall back to the select_idlest_group CPU selection mechanism, instead of trying to wake up the task on a CPU near its previous CPU. Fix that by always calling select_idle_sibling when doing an SD_BALANCE_WAKE wakeup. Signed-off-by: Rik van Riel <r...@redhat.com> --- kernel/sched/fair.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7570dd9..5d33fb1b 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4452,7 +4452,9 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f if (affine_sd) { if (cpu != prev_cpu && wake_affine(affine_sd, p, sync)) prev_cpu = cpu; + } + if (sd_flag & SD_BALANCE_WAKE) { new_cpu = select_idle_sibling(p, prev_cpu); goto unlock; } -- 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/