All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Nathanael Hoyle <nhoyle@hoyletech.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: scheduler nice 19 versus 'idle' behavior / static low-priority scheduling
Date: Fri, 30 Jan 2009 08:09:04 +0100	[thread overview]
Message-ID: <1233299344.4506.13.camel@marge.simson.net> (raw)
In-Reply-To: <1233298321.17301.18.camel@localhost>

On Fri, 2009-01-30 at 01:52 -0500, Nathanael Hoyle wrote:
> On Fri, 2009-01-30 at 07:24 +0100, Mike Galbraith wrote:

> > Sounds like a problem was recently fixed.  Can you try 2.6.29-rc3 or
> > 2.6.28.2?
> > 
> 
> I will try to do so as soon as I get the chance.  Do you have any
> specific info on the problem that you believe was fixed and/or the fix
> applied.

The commit text below also applies to +nice tasks.

commit 046e7f77d734778a3b2e7d51ce63da3dbe7a8168
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Thu Jan 15 14:53:39 2009 +0100

    sched: fix update_min_vruntime
    
    commit e17036dac189dd034c092a91df56aa740db7146d upstream.
    
    Impact: fix SCHED_IDLE latency problems
    
    OK, so we have 1 running task A (which is obviously curr and the tree is
    equally obviously empty).
    
    'A' nicely chugs along, doing its thing, carrying min_vruntime along as it
    goes.
    
    Then some whacko speed freak SCHED_IDLE task gets inserted due to SMP
    balancing, which is very likely far right, in that case
    
    update_curr
      update_min_vruntime
        cfs_rq->rb_leftmost := true (the crazy task sitting in a tree)
          vruntime = se->vruntime
    
    and voila, min_vruntime is waaay right of where it ought to be.
    
    OK, so why did I write it like that to begin with...
    
    Aah, yes.
    
    Say we've just dequeued current
    
    schedule
      deactivate_task(prev)
        dequeue_entity
          update_min_vruntime
    
    Then we'll set
    
      vruntime = cfs_rq->min_vruntime;
    
    we find !cfs_rq->curr, but do find someone in the tree. Then we _must_
    do vruntime = se->vruntime, because
    
     vruntime = min_vruntime(vruntime := cfs_rq->min_vruntime, se->vruntime)
    
    will not advance vruntime, and cause lags the other way around (which we
    fixed with that initial patch: 1af5f730fc1bf7c62ec9fb2d307206e18bf40a69
    (sched: more accurate min_vruntime accounting).
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Tested-by: Mike Galbraith <efault@gmx.de>
    Acked-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index 98345e4..06a68c4 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -283,7 +283,7 @@ static void update_min_vruntime(struct cfs_rq *cfs_rq)
 						   struct sched_entity,
 						   run_node);
 
-		if (vruntime == cfs_rq->min_vruntime)
+		if (!cfs_rq->curr)
 			vruntime = se->vruntime;
 		else
 			vruntime = min_vruntime(vruntime, se->vruntime);



  reply	other threads:[~2009-01-30  7:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30  5:49 scheduler nice 19 versus 'idle' behavior / static low-priority scheduling Nathanael Hoyle
2009-01-30  6:16 ` Jan Engelhardt
2009-01-30  6:40   ` Nathanael Hoyle
2009-01-30  7:21     ` Jan Engelhardt
2009-01-30  7:59       ` Nathanael Hoyle
2009-01-30  8:07         ` Mike Galbraith
2009-01-30  8:55           ` Nathanael Hoyle
2009-01-30  9:29             ` Mike Galbraith
2009-01-30 22:12           ` Brian Rogers
2009-01-31  5:38             ` Mike Galbraith
2009-01-31  9:08               ` Mike Galbraith
2009-02-02 23:57                 ` [stable] " Greg KH
2009-02-09 15:19                   ` Brian Rogers
2009-02-09 15:51                     ` Greg KH
2009-01-30  8:16         ` Nathanael Hoyle
2009-01-30 13:56           ` Jan Engelhardt
2009-01-30 14:15         ` Jan Engelhardt
2009-01-30  6:17 ` V.Radhakrishnan
2009-01-30  6:48   ` Nathanael Hoyle
2009-01-30 14:15     ` Jan Engelhardt
2009-01-30  6:24 ` Mike Galbraith
2009-01-30  6:52   ` Nathanael Hoyle
2009-01-30  7:09     ` Mike Galbraith [this message]
2009-01-30  8:50 ` Peter Zijlstra
2009-01-30  9:00   ` Nathanael Hoyle
2009-01-30  9:03     ` Peter Zijlstra
2009-01-30 10:18       ` Nathanael Hoyle
2009-01-30 10:31         ` Mike Galbraith
2009-01-30 10:40           ` Peter Zijlstra
2009-01-30 10:50             ` Mike Galbraith
2009-02-02 17:23 ` Lennart Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1233299344.4506.13.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhoyle@hoyletech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.