linux-kernel - [PATCH 2/2] sched/cfs: take into account current time segment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1492620257-30109-3-git-send-email-vincent.guittot@linaro.org>
Date:   Wed, 19 Apr 2017 18:44:17 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     peterz@...radead.org, mingo@...nel.org,
        linux-kernel@...r.kernel.org
Cc:     dietmar.eggemann@....com, Morten.Rasmussen@....com,
        yuyang.du@...el.com, pjt@...gle.com, bsegall@...gle.com,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: [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@...aro.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