• S
    sched: Fix select_idle_sibling() logic in select_task_rq_fair() · 99bd5e2f
    Suresh Siddha 提交于
    Issues in the current select_idle_sibling() logic in select_task_rq_fair()
    in the context of a task wake-up:
    
    a) Once we select the idle sibling, we use that domain (spanning the cpu that
       the task is currently woken-up and the idle sibling that we found) in our
       wake_affine() decisions. This domain is completely different from the
       domain(we are supposed to use) that spans the cpu that the task currently
       woken-up and the cpu where the task previously ran.
    
    b) We do select_idle_sibling() check only for the cpu that the task is
       currently woken-up on. If select_task_rq_fair() selects the previously run
       cpu for waking the task, doing a select_idle_sibling() check
       for that cpu also helps and we don't do this currently.
    
    c) In the scenarios where the cpu that the task is woken-up is busy but
       with its HT siblings are idle, we are selecting the task be woken-up
       on the idle HT sibling instead of a core that it previously ran
       and currently completely idle. i.e., we are not taking decisions based on
       wake_affine() but directly selecting an idle sibling that can cause
       an imbalance at the SMT/MC level which will be later corrected by the
       periodic load balancer.
    
    Fix this by first going through the load imbalance calculations using
    wake_affine() and once we make a decision of woken-up cpu vs previously-ran cpu,
    then choose a possible idle sibling for waking up the task on.
    Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
    LKML-Reference: <1270079265.7835.8.camel@sbs-t61.sc.intel.com>
    Signed-off-by: NIngo Molnar <mingo@elte.hu>
    99bd5e2f
sched_fair.c 92.8 KB