Skip to content

L
linux-davinci
Switch branch/tag
  1. 10 Sep, 2009 2 commits
    • Ingo Molnar's avatar
      sched: Fix sched::sched_stat_wait tracepoint field · e1f84508
      Ingo Molnar authored 
      This weird perf trace output:

  cc1-9943  [001]  2802.059479616: sched_stat_wait: task: as:9944 wait: 2801938766276 [ns]

Is caused by setting one component field of the delta to zero
a bit too early. Move it to later.

( Note, this does not affect the NEW_FAIR_SLEEPERS interactivity bug,
  it's just a reporting bug in essence. )
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nikos Chantziaras <realnc@arcor.de>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <4AA93D34.8040500@arcor.de>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e1f84508
    • Ingo Molnar's avatar
      sched: Disable NEW_FAIR_SLEEPERS for now · 3f2aa307
      Ingo Molnar authored 
      Nikos Chantziaras and Jens Axboe reported that turning off
NEW_FAIR_SLEEPERS improves desktop interactivity visibly.

Nikos described his experiences the following way:

  " With this setting, I can do "nice -n 19 make -j20" and
    still have a very smooth desktop and watch a movie at
    the same time.  Various other annoyances (like the
    "logout/shutdown/restart" dialog of KDE not appearing
    at all until the background fade-out effect has finished)
    are also gone.  So this seems to be the single most
    important setting that vastly improves desktop behavior,
    at least here. "

Jens described it the following way, referring to a 10-seconds
xmodmap scheduling delay he was trying to debug:

  " Then I tried switching NO_NEW_FAIR_SLEEPERS on, and then
    I get:

    Performance counter stats for 'xmodmap .xmodmap-carl':

         9.009137  task-clock-msecs         #      0.447 CPUs
               18  context-switches         #      0.002 M/sec
                1  CPU-migrations           #      0.000 M/sec
              315  page-faults              #      0.035 M/sec

    0.020167093  seconds time elapsed

    Woot! "

So disable it for now. In perf trace output i can see weird
delta timestamps:

  cc1-9943  [001]  2802.059479616: sched_stat_wait: task: as:9944 wait: 2801938766276 [ns]

That nsec field is not supposed to be that large. More digging
is needed - but lets turn it off while the real bug is found.
Reported-by: default avatarNikos Chantziaras <realnc@arcor.de>
Tested-by: default avatarNikos Chantziaras <realnc@arcor.de>
Reported-by: default avatarJens Axboe <jens.axboe@oracle.com>
Tested-by: default avatarJens Axboe <jens.axboe@oracle.com>
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <4AA93D34.8040500@arcor.de>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3f2aa307
  3. 09 Sep, 2009 3 commits
  5. 08 Sep, 2009 1 commit
    • Mike Galbraith's avatar
      sched: Ensure that a child can't gain time over it's parent after fork() · b5d9d734
      Mike Galbraith authored 
      A fork/exec load is usually "pass the baton", so the child
should never be placed behind the parent.  With START_DEBIT we
make room for the new task, but with child_runs_first, that
room comes out of the _parent's_ hide. There's nothing to say
that the parent wasn't ahead of min_vruntime at fork() time,
which means that the "baton carrier", who is essentially the
parent in drag, can gain time and increase scheduling latencies
for waiters.

With NEW_FAIR_SLEEPERS + START_DEBIT + child_runs_first
enabled, we essentially pass the sleeper fairness off to the
child, which is fine, but if we don't base placement on the
parent's updated vruntime, we can end up compounding latency
woes if the child itself then does fork/exec.  The debit
incurred at fork doesn't hurt the parent who is then going to
sleep and maybe exit, but the child who acquires the error
harms all comers.

This improves latencies of make -j<n> kernel build workloads.
Reported-by: default avatarJens Axboe <jens.axboe@oracle.com>
Signed-off-by: default avatarMike Galbraith <efault@gmx.de>
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b5d9d734
  7. 07 Sep, 2009 3 commits
  9. 04 Sep, 2009 13 commits
  11. 02 Sep, 2009 3 commits
  13. 29 Aug, 2009 1 commit
  15. 28 Aug, 2009 2 commits
    • Peter Zijlstra's avatar
      sched: Fix division by zero - really · 34d76c41
      Peter Zijlstra authored 
      When re-computing the shares for each task group's cpu
representation we need the ratio of weight on each cpu vs the
total weight of the sched domain.

Since load-balancing is loosely (read not) synchronized, the
weight of individual cpus can change between doing the sum and
calculating the ratio.

The previous patch dealt with only one of the race scenarios,
this patch side steps them all by saving a snapshot of all the
individual cpu weights, thereby always working on a consistent
set.
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: torvalds@linux-foundation.org
Cc: jes@sgi.com
Cc: jens.axboe@oracle.com
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <1251371336.18584.77.camel@twins>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      34d76c41
    • Linus Torvalds's avatar
      Linux 2.6.31-rc8 · 326ba501
      Linus Torvalds authored
      326ba501
  17. 27 Aug, 2009 12 commits