public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: XingChao Wang <wxc200@gmail.com>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	mingo@elte.hu, Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: check_preempt_tick() check vruntime mistake?
Date: Fri, 11 Dec 2009 08:25:26 +0100	[thread overview]
Message-ID: <1260516326.6090.61.camel@marge.simson.net> (raw)
In-Reply-To: <fd6b62c10912102017g56b8651aj2b8cbe569b0f90a6@mail.gmail.com>

On Fri, 2009-12-11 at 12:17 +0800, XingChao Wang wrote:
> Hi Ingo,peter,
> 
> When check_preempt_tick() selects next leftmost sched_entity,it
> calculates delta vruntime of curr and leftmost entity, then compares
> it with ideal_runtime. But ideal_runtime is real-time type, need
> convert it to virtual-time ,right?

Why?  The scheduler converges vruntimes to within min_granularity,
that's it's mission.  What this test is trying to say is that if the
awakened task's lag has grown to be more than your quantum while we
waited for the tick to come along, you need to get out of it's way so it
can catch up.

Now, there are a couple ~problems in that in it's current form, it
offers protection to SCHED_BATCH and SCHED_IDLE tasks, and the test..

if (delta_exec < sysctl_sched_min_granularity)
	return;

..is... not exactly optimal for light weight tasks, but the lighter you
get, the more likely you'd already have been preempted...

I have a patch which excludes these, and computes min runtime based on
differential in task weights.  These are the only things I see ~wrong.
ideal_runtime is weighted, and is our "fair unit of measure", so using
it to measure acceptable lag distance is correct AFAIKS.

> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index 37087a7..9b903d4 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -840,7 +840,7 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct
> sched_entity *curr)
>                 struct sched_entity *se = __pick_next_entity(cfs_rq);
>                 s64 delta = curr->vruntime - se->vruntime;
> 
> -               if (delta > ideal_runtime)
> +               if (delta > calc_delta_fair(ideal_runtime, curr))
>                         resched_task(rq_of(cfs_rq)->curr);
>         }
>  }
> 
> thanks
> --wang xingchao
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


      reply	other threads:[~2009-12-11  7:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-11  4:17 check_preempt_tick() check vruntime mistake? XingChao Wang
2009-12-11  7:25 ` Mike Galbraith [this message]

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=1260516326.6090.61.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=wxc200@gmail.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