[PATCH]sched: convert wall-time to vruntime for check_preempt_tick

[Shaohua Li]

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 <***@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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Mike Galbraith]

Post by Shaohua Li
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.

Post by Shaohua Li
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Shaohua Li]

Post by Mike Galbraith

Post by Shaohua Li
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Mike Galbraith]

Post by Shaohua Li

Post by Mike Galbraith

Post by Shaohua Li
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Shaohua Li]

Post by Mike Galbraith

Post by Shaohua Li

Post by Mike Galbraith

Post by Shaohua Li
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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Mike Galbraith]

Post by Shaohua Li

Post by Mike Galbraith

Post by Shaohua Li

Post by Mike Galbraith

Post by Shaohua Li
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[t***@gmail.com]

Hi Shaohua:
您好，我最近也在看 schedule 的代码，同样发现了这个问题， 用了墙上时间和虚拟时间作比较； 感觉这样比较度量不一样； 看最新的代码用的还是 ideal_time = sched_slise(); 不知您有没有弄懂为什么这样作比较， 是什么意图； 期待您的回复。

Best Regard