In check_preempt_tick(), delta is vruntime and ideal_runtime is wall runtime.
Comparing vruntime and ideal_runtime looks buggy.
Signed-off-by: Shaohua Li <[email protected]>
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index 3f7ec9e..0b76e3a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -1121,7 +1121,7 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
if (delta < 0)
return;
- if (delta > ideal_runtime)
+ if (delta > calc_delta_fair(ideal_runtime, curr))
resched_task(rq_of(cfs_rq)->curr);
}
}
On Thu, 2011-04-07 at 20:43 +0800, Shaohua Li wrote:
> In check_preempt_tick(), delta is vruntime and ideal_runtime is wall runtime.
> Comparing vruntime and ideal_runtime looks buggy.
Why is that buggy? It's a distance in units ns, ala wakeup_granularity,
a number. This number just happens to be variable.
> Signed-off-by: Shaohua Li <[email protected]>
>
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index 3f7ec9e..0b76e3a 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -1121,7 +1121,7 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
> if (delta < 0)
> return;
>
> - if (delta > ideal_runtime)
> + if (delta > calc_delta_fair(ideal_runtime, curr))
> resched_task(rq_of(cfs_rq)->curr);
> }
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2011-04-07 at 21:34 +0800, Mike Galbraith wrote:
> On Thu, 2011-04-07 at 20:43 +0800, Shaohua Li wrote:
> > In check_preempt_tick(), delta is vruntime and ideal_runtime is wall runtime.
> > Comparing vruntime and ideal_runtime looks buggy.
>
> Why is that buggy? It's a distance in units ns, ala wakeup_granularity,
> a number. This number just happens to be variable.
vruntime is scaled wall-time. In all other places we do the scale from
my understanding. I'm wondering why not do it here.
On Fri, 2011-04-08 at 08:35 +0800, Shaohua Li wrote:
> On Thu, 2011-04-07 at 21:34 +0800, Mike Galbraith wrote:
> > On Thu, 2011-04-07 at 20:43 +0800, Shaohua Li wrote:
> > > In check_preempt_tick(), delta is vruntime and ideal_runtime is wall runtime.
> > > Comparing vruntime and ideal_runtime looks buggy.
> >
> > Why is that buggy? It's a distance in units ns, ala wakeup_granularity,
> > a number. This number just happens to be variable.
> vruntime is scaled wall-time. In all other places we do the scale from
> my understanding. I'm wondering why not do it here.
The purpose was to ensure that there is not too much spread, just like
wakeup preemption. Using the number that determines tick induced spread
as the spread caliper seems perfectly fine to me.
-Mike
On Fri, 2011-04-08 at 10:49 +0800, Mike Galbraith wrote:
> On Fri, 2011-04-08 at 08:35 +0800, Shaohua Li wrote:
> > On Thu, 2011-04-07 at 21:34 +0800, Mike Galbraith wrote:
> > > On Thu, 2011-04-07 at 20:43 +0800, Shaohua Li wrote:
> > > > In check_preempt_tick(), delta is vruntime and ideal_runtime is wall runtime.
> > > > Comparing vruntime and ideal_runtime looks buggy.
> > >
> > > Why is that buggy? It's a distance in units ns, ala wakeup_granularity,
> > > a number. This number just happens to be variable.
> > vruntime is scaled wall-time. In all other places we do the scale from
> > my understanding. I'm wondering why not do it here.
>
> The purpose was to ensure that there is not too much spread, just like
> wakeup preemption. Using the number that determines tick induced spread
> as the spread caliper seems perfectly fine to me.
But we scale wakeup_granularity too for wakeup preemption, see
wakeup_gran(), am I missing anything?
On Fri, 2011-04-08 at 12:55 +0800, Shaohua Li wrote:
> On Fri, 2011-04-08 at 10:49 +0800, Mike Galbraith wrote:
> > On Fri, 2011-04-08 at 08:35 +0800, Shaohua Li wrote:
> > > On Thu, 2011-04-07 at 21:34 +0800, Mike Galbraith wrote:
> > > > On Thu, 2011-04-07 at 20:43 +0800, Shaohua Li wrote:
> > > > > In check_preempt_tick(), delta is vruntime and ideal_runtime is wall runtime.
> > > > > Comparing vruntime and ideal_runtime looks buggy.
> > > >
> > > > Why is that buggy? It's a distance in units ns, ala wakeup_granularity,
> > > > a number. This number just happens to be variable.
> > > vruntime is scaled wall-time. In all other places we do the scale from
> > > my understanding. I'm wondering why not do it here.
> >
> > The purpose was to ensure that there is not too much spread, just like
> > wakeup preemption. Using the number that determines tick induced spread
> > as the spread caliper seems perfectly fine to me.
> But we scale wakeup_granularity too for wakeup preemption, see
> wakeup_gran(), am I missing anything?
Only because we want lighter tasks to be easier to preempt, and heavier
tasks harder. Weight is already built into vruntime.
-Mike