Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1626487 > unrolled thread

[PATCH 0/2] sched/cfs: make util/load_avg stable

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] sched/cfs: make util/load_avg stable  Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 18:40 +0200
    [PATCH 2/2] sched/cfs: take into account current time segment Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 18:40 +0200
    [PATCH 1/2] sched/cfs: make util/load_avg more stable Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 18:40 +0200
    [PATCH v2] sched/cfs: make util/load_avg more stable Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 19:00 +0200
    [PATCH 1/2] sched/cfs: make util/load_avg more stable Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 19:20 +0200
    [PATCH 2/2] sched/cfs: take into account current time segment Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 19:20 +0200
    [PATCH 0/2] sched/cfs: make util/load_avg stable  Vincent Guittot <vincent.guittot@linaro.org> - 2017-04-19 19:20 +0200

#1626487 — [PATCH 0/2] sched/cfs: make util/load_avg stable

In the current implementation of load/util_avg, we assume that the ongoing
time segment has fully elapsed and util/load_sum is divided by LOAD_AVG_MAX,
even if part of the time segment still remains to run . As a consequence,
this remaining part is considered as idle time and generates unexpected
variations of util_avg of a busy CPU in the range ]1002..1024[ whereas
util_avg should stay at 1023.

The 1st patch implements Peter's proposal to remove the contribution of the
current time segment when computing the util/load_avg. The 2nd one keeps
using the current segment but update the max value instead. Both solutions
make load/util_avg being stable with the advantage of using the most up to
date value for the 2nd patch. I have split it into 2 patches to show the 2
versions but if the 2nd patch looks ok, we should probably squashed them into
one.

Vincent Guittot (2):
  sched/cfs: make util/load_avg more stable
  sched/cfs: take into account current segment

 kernel/sched/fair.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

[toc] | [next] | [standalone]

#1626491 — [PATCH 2/2] sched/cfs: take into account current time segment

To not consider the current time segment adds unwanted latency in the
load/util_avg responsivness especially when the time is scaled instead of
the contribution. Instead of waiting for the current time segment to have
fully elapsed before accounting it in load/util_avg, we can already account
the elapsed part but change the range used to compute load/util_avg
accordingly.
At the very beginning of a new time segment, the past segments have been
decayed and the max value is MAX_LOAD_AVG*y. At the very end of the current
time segment, the max value becomes 1024(us) + MAX_LOAD_AVG*y which is equal
to MAX_LOAD_AVG. In fact, the max value is
sa->period_contrib + MAX_LOAD_AVG*y at any time in the time segment.

Taking advantage of the fact that MAX_LOAD_AVG*y == MAX_LOAD_AVG-1024, the
range becomes [0..MAX_LOAD_AVG-1024+sa->period_contrib].

As the elapsed part is already accounted in load/util_sum, we update the max
value according to the current position in the time segment instead of
removing its contribution.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/fair.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f74da94..c3b8f0f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3017,15 +3017,12 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
 	/*
 	 * Step 2: update *_avg.
 	 */
-	sa->load_avg = div_u64((sa->load_sum - sa->period_contrib * weight),
-					(LOAD_AVG_MAX - 1024));
+	sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX - 1024 + sa->period_contrib);
 	if (cfs_rq) {
 		cfs_rq->runnable_load_avg =
-			div_u64((cfs_rq->runnable_load_sum - sa->period_contrib * weight),
-					(LOAD_AVG_MAX - 1024));
+			div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX - 1024 + sa->period_contrib);
 	}
-	sa->util_avg = (sa->util_sum - (running * sa->period_contrib << SCHED_CAPACITY_SHIFT)) /
-					(LOAD_AVG_MAX - 1024);
+	sa->util_avg = sa->util_sum / (LOAD_AVG_MAX - 1024 + sa->period_contrib);
 
 	return 1;
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1626499 — [PATCH 1/2] sched/cfs: make util/load_avg more stable

In the current implementation of load/util_avg, we assume that the ongoing
time segment has fully elapsed, and util/load_sum is divided by LOAD_AVG_MAX,
even if part of the time segment still remains. As a consequence, this
remaining part is considered as idle time and generates unexpected variations
of util_avg of a busy CPU in the range ]1002..1024[ whereas util_avg should
stay at 1023.
In order to keep the metric stable, we should not consider the ongoing time
segment when computing load/util_avg but only the segments that have already
fully elapsed.
:if expand("%") == ""|browse confirm w|else|confirm w|endif

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/fair.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3f83a35..f74da94 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3017,12 +3017,15 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
 	/*
 	 * Step 2: update *_avg.
 	 */
-	sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX);
+	sa->load_avg = div_u64((sa->load_sum - sa->period_contrib * weight),
+					(LOAD_AVG_MAX - 1024));
 	if (cfs_rq) {
 		cfs_rq->runnable_load_avg =
-			div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX);
+			div_u64((cfs_rq->runnable_load_sum - sa->period_contrib * weight),
+					(LOAD_AVG_MAX - 1024));
 	}
-	sa->util_avg = sa->util_sum / LOAD_AVG_MAX;
+	sa->util_avg = (sa->util_sum - (running * sa->period_contrib << SCHED_CAPACITY_SHIFT)) /
+					(LOAD_AVG_MAX - 1024);
 
 	return 1;
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1626535 — [PATCH v2] sched/cfs: make util/load_avg more stable

In the current implementation of load/util_avg, we assume that the ongoing
time segment has fully elapsed, and util/load_sum is divided by LOAD_AVG_MAX,
even if part of the time segment still remains to run. As a consequence, this
remaining part is considered as idle time and generates unexpected variations
of util_avg of a busy CPU in the range ]1002..1024[ whereas util_avg should
stay at 1023.

In order to keep the metric stable, we should not consider the ongoing time
segment when computing load/util_avg but only the segments that have already
fully elapsed. Bu to not consider the current time segment adds unwanted
latency in the load/util_avg responsivness especially when the time is scaled
instead of the contribution. Instead of waiting for the current time segment
to have fully elapsed before accounting it in load/util_avg, we can already
account the elapsed part but change the range used to compute load/util_avg
accordingly.

At the very beginning of a new time segment, the past segments have been
decayed and the max value is MAX_LOAD_AVG*y. At the very end of the current
time segment, the max value becomes 1024(us) + MAX_LOAD_AVG*y which is equal
to MAX_LOAD_AVG. In fact, the max value is
sa->period_contrib + MAX_LOAD_AVG*y at any time in the time segment.

Taking advantage of the fact that MAX_LOAD_AVG*y == MAX_LOAD_AVG-1024, the
range becomes [0..MAX_LOAD_AVG-1024+sa->period_contrib].

As the elapsed part is already accounted in load/util_sum, we update the max
value according to the current position in the time segment instead of
removing its contribution.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---

Fold both patches in one

 kernel/sched/fair.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3f83a35..c3b8f0f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3017,12 +3017,12 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
 	/*
 	 * Step 2: update *_avg.
 	 */
-	sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX);
+	sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX - 1024 + sa->period_contrib);
 	if (cfs_rq) {
 		cfs_rq->runnable_load_avg =
-			div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX);
+			div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX - 1024 + sa->period_contrib);
 	}
-	sa->util_avg = sa->util_sum / LOAD_AVG_MAX;
+	sa->util_avg = sa->util_sum / (LOAD_AVG_MAX - 1024 + sa->period_contrib);
 
 	return 1;
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1626609 — [PATCH 1/2] sched/cfs: make util/load_avg more stable

In the current implementation of load/util_avg, we assume that the ongoing
time segment has fully elapsed, and util/load_sum is divided by LOAD_AVG_MAX,
even if part of the time segment still remains. As a consequence, this
remaining part is considered as idle time and generates unexpected variations
of util_avg of a busy CPU in the range ]1002..1024[ whereas util_avg should
stay at 1023.
In order to keep the metric stable, we should not consider the ongoing time
segment when computing load/util_avg but only the segments that have already
fully elapsed.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---

Sorry some unexpected characters appeared in the commit message of previous
version

 kernel/sched/fair.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3f83a35..f74da94 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3017,12 +3017,15 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
 	/*
 	 * Step 2: update *_avg.
 	 */
-	sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX);
+	sa->load_avg = div_u64((sa->load_sum - sa->period_contrib * weight),
+					(LOAD_AVG_MAX - 1024));
 	if (cfs_rq) {
 		cfs_rq->runnable_load_avg =
-			div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX);
+			div_u64((cfs_rq->runnable_load_sum - sa->period_contrib * weight),
+					(LOAD_AVG_MAX - 1024));
 	}
-	sa->util_avg = sa->util_sum / LOAD_AVG_MAX;
+	sa->util_avg = (sa->util_sum - (running * sa->period_contrib << SCHED_CAPACITY_SHIFT)) /
+					(LOAD_AVG_MAX - 1024);
 
 	return 1;
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1626612 — [PATCH 2/2] sched/cfs: take into account current time segment

To not consider the current time segment adds unwanted latency in the
load/util_avg responsivness especially when the time is scaled instead of
the contribution. Instead of waiting for the current time segment to have
fully elapsed before accounting it in load/util_avg, we can already account
the elapsed part but change the range used to compute load/util_avg
accordingly.
At the very beginning of a new time segment, the past segments have been
decayed and the max value is MAX_LOAD_AVG*y. At the very end of the current
time segment, the max value becomes 1024(us) + MAX_LOAD_AVG*y which is equal
to MAX_LOAD_AVG. In fact, the max value is
sa->period_contrib + MAX_LOAD_AVG*y at any time in the time segment.

Taking advantage of the fact that MAX_LOAD_AVG*y == MAX_LOAD_AVG-1024, the
range becomes [0..MAX_LOAD_AVG-1024+sa->period_contrib].

As the elapsed part is already accounted in load/util_sum, we update the max
value according to the current position in the time segment instead of
removing its contribution.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
 kernel/sched/fair.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f74da94..c3b8f0f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3017,15 +3017,12 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
 	/*
 	 * Step 2: update *_avg.
 	 */
-	sa->load_avg = div_u64((sa->load_sum - sa->period_contrib * weight),
-					(LOAD_AVG_MAX - 1024));
+	sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX - 1024 + sa->period_contrib);
 	if (cfs_rq) {
 		cfs_rq->runnable_load_avg =
-			div_u64((cfs_rq->runnable_load_sum - sa->period_contrib * weight),
-					(LOAD_AVG_MAX - 1024));
+			div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX - 1024 + sa->period_contrib);
 	}
-	sa->util_avg = (sa->util_sum - (running * sa->period_contrib << SCHED_CAPACITY_SHIFT)) /
-					(LOAD_AVG_MAX - 1024);
+	sa->util_avg = sa->util_sum / (LOAD_AVG_MAX - 1024 + sa->period_contrib);
 
 	return 1;
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1626621

In the current implementation of load/util_avg, we assume that the ongoing
time segment has fully elapsed and util/load_sum is divided by LOAD_AVG_MAX,
even if part of the time segment still remains to run . As a consequence,
this remaining part is considered as idle time and generates unexpected
variations of util_avg of a busy CPU in the range ]1002..1024[ whereas
util_avg should stay at 1023.

The 1st patch implements Peter's proposal to remove the contribution of the
current time segment when computing the util/load_avg. The 2nd one keeps
using the current segment but update the max value instead. Both solutions
make load/util_avg being stable with the advantage of using the most up to
date value for the 2nd patch. I have split it into 2 patches to show the 2
versions but if the 2nd patch looks ok, we should probably squashed them into
one.

Vincent Guittot (2):
  sched/cfs: make util/load_avg more stable
  sched/cfs: take into account current segment

 kernel/sched/fair.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web