LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH]sched: convert wall-time to vruntime for check_preempt_tick
@ 2011-04-07 12:43 Shaohua Li
  2011-04-07 13:34 ` Mike Galbraith
  0 siblings, 1 reply; 6+ messages in thread
From: Shaohua Li @ 2011-04-07 12:43 UTC (permalink / raw)
  To: linux-kernel; +Cc: mingo, zheng.z.yan

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 <shaohua.li@intel.com>

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);
 	}
 }

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH]sched: convert wall-time to vruntime for check_preempt_tick
  2011-04-07 12:43 [PATCH]sched: convert wall-time to vruntime for check_preempt_tick Shaohua Li
@ 2011-04-07 13:34 ` Mike Galbraith
  2011-04-08  0:35   ` Shaohua Li
  0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2011-04-07 13:34 UTC (permalink / raw)
  To: Shaohua Li; +Cc: linux-kernel, mingo, zheng.z.yan

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 <shaohua.li@intel.com>
> 
> 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 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/



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH]sched: convert wall-time to vruntime for check_preempt_tick
  2011-04-07 13:34 ` Mike Galbraith
@ 2011-04-08  0:35   ` Shaohua Li
  2011-04-08  2:49     ` Mike Galbraith
  0 siblings, 1 reply; 6+ messages in thread
From: Shaohua Li @ 2011-04-08  0:35 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: linux-kernel, mingo, Yan, Zheng Z

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH]sched: convert wall-time to vruntime for check_preempt_tick
  2011-04-08  0:35   ` Shaohua Li
@ 2011-04-08  2:49     ` Mike Galbraith
  2011-04-08  4:55       ` Shaohua Li
  0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2011-04-08  2:49 UTC (permalink / raw)
  To: Shaohua Li; +Cc: linux-kernel, mingo, Yan, Zheng Z

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH]sched: convert wall-time to vruntime for check_preempt_tick
  2011-04-08  2:49     ` Mike Galbraith
@ 2011-04-08  4:55       ` Shaohua Li
  2011-04-08  5:31         ` Mike Galbraith
  0 siblings, 1 reply; 6+ messages in thread
From: Shaohua Li @ 2011-04-08  4:55 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: linux-kernel, mingo, Yan, Zheng Z

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?


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH]sched: convert wall-time to vruntime for check_preempt_tick
  2011-04-08  4:55       ` Shaohua Li
@ 2011-04-08  5:31         ` Mike Galbraith
  0 siblings, 0 replies; 6+ messages in thread
From: Mike Galbraith @ 2011-04-08  5:31 UTC (permalink / raw)
  To: Shaohua Li; +Cc: linux-kernel, mingo, Yan, Zheng Z

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-04-08  5:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-07 12:43 [PATCH]sched: convert wall-time to vruntime for check_preempt_tick Shaohua Li
2011-04-07 13:34 ` Mike Galbraith
2011-04-08  0:35   ` Shaohua Li
2011-04-08  2:49     ` Mike Galbraith
2011-04-08  4:55       ` Shaohua Li
2011-04-08  5:31         ` Mike Galbraith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).