mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome