1. 28 8月, 2007 5 次提交
    • I
      sched: small schedstat fix · 213c8af6
      Ingo Molnar 提交于
      small schedstat fix: the cfs_rq->wait_runtime 'sum of all runtimes'
      statistics counters missed newly forked tasks and thus had a constant
      negative skew. Fix this.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      213c8af6
    • I
      sched: fix wait_start_fair condition in update_stats_wait_end() · b77d69db
      Ingo Molnar 提交于
      Peter Zijlstra noticed the following bug in SCHED_FEAT_SKIP_INITIAL (which
      is disabled by default at the moment): it relies on se.wait_start_fair
      being 0 while update_stats_wait_end() did not recognize a 0 value,
      so instead of 'skipping' the initial interval we gave the new child
      a maximum boost of +runtime-limit ...
      
      (No impact on the default kernel, but nice to fix for completeness.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      b77d69db
    • T
      sched: call update_curr() in task_tick_fair() · 7109c442
      Ting Yang 提交于
      update the fair-clock before using it for the key value.
      
      [ mingo@elte.hu: small cleanups. ]
      Signed-off-by: NTing Yang <tingy@cs.umass.edu>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      7109c442
    • I
      sched: make the scheduler converge to the ideal latency · f6cf891c
      Ingo Molnar 提交于
      de-HZ-ification of the granularity defaults unearthed a pre-existing
      property of CFS: while it correctly converges to the granularity goal,
      it does not prevent run-time fluctuations in the range of
      [-gran ... 0 ... +gran].
      
      With the increase of the granularity due to the removal of HZ
      dependencies, this becomes visible in chew-max output (with 5 tasks
      running):
      
       out:  28 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   37 .   40
       out:  27 . 27. 32 | flu:  0 .  0 | ran:   17 .   13 | per:   44 .   40
       out:  27 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   36 .   40
       out:  29 . 27. 32 | flu:  2 .  0 | ran:   17 .   13 | per:   46 .   40
       out:  28 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   37 .   40
       out:  29 . 27. 32 | flu:  0 .  0 | ran:   18 .   13 | per:   47 .   40
       out:  28 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   37 .   40
      
      average slice is the ideal 13 msecs and the period is picture-perfect 40
      msecs. But the 'ran' field fluctuates around 13.33 msecs and there's no
      mechanism in CFS to keep that from happening: it's a perfectly valid
      solution that CFS finds.
      
      to fix this we add a granularity/preemption rule that knows about
      the "target latency", which makes tasks that run longer than the ideal
      latency run a bit less. The simplest approach is to simply decrease the
      preemption granularity when a task overruns its ideal latency. For this
      we have to track how much the task executed since its last preemption.
      
      ( this adds a new field to task_struct, but we can eliminate that
        overhead in 2.6.24 by putting all the scheduler timestamps into an
        anonymous union. )
      
      with this change in place, chew-max output is fluctuation-less all
      around:
      
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  1 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  1 | ran:   13 .   13 | per:   41 .   40
      
      this patch has no impact on any fastpath or on any globally observable
      scheduling property. (unless you have sharp enough eyes to see
      millisecond-level ruckles in glxgears smoothness :-)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      f6cf891c
    • M
      sched: fix sleeper bonus limit · 5f01d519
      Mike Galbraith 提交于
      There is an Amarok song switch time increase (regression) under
      hefty load.
      
      What is happening is that sleeper_bonus is never consumed, and only
      rarely goes below runtime_limit, so for the most part, Amarok isn't
      getting any bonus at all.  We're keeping sleeper_bonus right at
      runtime_limit (sched_latency == sched_runtime_limit == 40ms) forever, ie
      we don't consume if we're lower that that, and don't add if we're above
      it.  One Amarok thread waking (or anybody else) will push us past the
      threshold, so the next thread waking gets nada, but will reap pain from
      the previous thread waking until we drop back to runtime_limit.  It
      looks to me like under load, some random task gets a bonus, and
      everybody else pays, whether deserving or not.
      
      This diff fixed the regression for me at any load rate.
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      5f01d519
  2. 26 8月, 2007 2 次提交
  3. 25 8月, 2007 6 次提交
  4. 13 8月, 2007 1 次提交
    • I
      sched: fix sleeper bonus · 5d2b3d36
      Ingo Molnar 提交于
      Peter Ziljstra noticed that the sleeper bonus deduction code
      was not properly rate-limited: a task that scheduled more
      frequently would get a disproportionately large deduction.
      So limit the deduction to delta_exec.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5d2b3d36
  5. 11 8月, 2007 1 次提交
  6. 09 8月, 2007 25 次提交