linux-kernel - [PATCH 1/1] sched/fair: Update min

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: <20231116105425.84773-2-s921975628@gmail.com>
Date:   Thu, 16 Nov 2023 18:54:25 +0800
From:   Yiwei Lin <s921975628@...il.com>
To:     mingo@...hat.com, peterz@...radead.org
Cc:     vincent.guittot@...aro.org, dietmar.eggemann@....com,
        wuyun.abel@...edance.com, linux-kernel@...r.kernel.org,
        s921975628@...il.com
Subject: [PATCH 1/1] sched/fair: Update min_vruntime in more relaxed way

As EEVDF adopts lag-based solution which is irrespective of
min_vruntime like CFS before, min_vruntime is only used as
an offset to avoid overflow on evaluation of avg_vruntime now.
Rely on the fact we will always update_curr() before change
to cfs_rq, it seems to make sense if we just
update_min_vruntime() with update_curr() to reduce the cost.

Signed-off-by: Yiwei Lin <s921975628@...il.com>
---
 kernel/sched/fair.c | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 07f555857..5c40adfae 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3815,17 +3815,8 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
 	enqueue_load_avg(cfs_rq, se);
 	if (se->on_rq) {
 		update_load_add(&cfs_rq->load, se->load.weight);
-		if (!curr) {
-			/*
-			 * The entity's vruntime has been adjusted, so let's check
-			 * whether the rq-wide min_vruntime needs updated too. Since
-			 * the calculations above require stable min_vruntime rather
-			 * than up-to-date one, we do the update at the end of the
-			 * reweight process.
-			 */
+		if (!curr)
 			__enqueue_entity(cfs_rq, se);
-			update_min_vruntime(cfs_rq);
-		}
 	}
 }
 
@@ -5347,15 +5338,6 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
 
 	update_cfs_group(se);
 
-	/*
-	 * Now advance min_vruntime if @se was the entity holding it back,
-	 * except when: DEQUEUE_SAVE && !DEQUEUE_MOVE, in this case we'll be
-	 * put back on, and if we advance min_vruntime, we'll be placed back
-	 * further than we started -- ie. we'll be penalized.
-	 */
-	if ((flags & (DEQUEUE_SAVE | DEQUEUE_MOVE)) != DEQUEUE_SAVE)
-		update_min_vruntime(cfs_rq);
-
 	if (cfs_rq->nr_running == 0)
 		update_idle_cfs_rq_clock_pelt(cfs_rq);
 }
-- 
2.34.1