1. 23 Apr, 2010 3 commits
    • Suresh Siddha's avatar
      sched: Fix select_idle_sibling() logic in select_task_rq_fair() · 99bd5e2f
      Suresh Siddha authored
      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: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1270079265.7835.8.camel@sbs-t61.sc.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      99bd5e2f
    • Peter Zijlstra's avatar
      sched: Pre-compute cpumask_weight(sched_domain_span(sd)) · 669c55e9
      Peter Zijlstra authored
      Dave reported that his large SPARC machines spend lots of time in
      hweight64(), try and optimize some of those needless cpumask_weight()
      invocations (esp. with the large offstack cpumasks these are very
      expensive indeed).
      Reported-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      669c55e9
    • Peter Zijlstra's avatar
      sched: Cure load average vs NO_HZ woes · 74f5187a
      Peter Zijlstra authored
      Chase reported that due to us decrementing calc_load_task prematurely
      (before the next LOAD_FREQ sample), the load average could be scewed
      by as much as the number of CPUs in the machine.
      
      This patch, based on Chase's patch, cures the problem by keeping the
      delta of the CPU going into NO_HZ idle separately and folding that in
      on the next LOAD_FREQ update.
      
      This restores the balance and we get strict LOAD_FREQ period samples.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarChase Douglas <chase.douglas@canonical.com>
      LKML-Reference: <1271934490.1776.343.camel@laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      74f5187a
  2. 15 Apr, 2010 2 commits
  3. 14 Apr, 2010 1 commit
  4. 13 Apr, 2010 34 commits