linux-kernel - [PATCH] sched: Improve the accuracy of sched_stat

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240322081521.2687856-1-zhangqiao22@huawei.com>
Date: Fri, 22 Mar 2024 16:15:21 +0800
From: Zhang Qiao <zhangqiao22@...wei.com>
To: <mingo@...hat.com>, <peterz@...radead.org>, <juri.lelli@...hat.com>,
	<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
	<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
	<bristot@...hat.com>, <vschneid@...hat.com>
CC: <linux-kernel@...r.kernel.org>, <qianjun.kernel@...il.com>,
	<laoar.shao@...il.com>, Zhang Qiao <zhangqiao22@...wei.com>
Subject: [PATCH] sched: Improve the accuracy of sched_stat_wait statistics for rt and dl

Where commit b9c88f752268 ("sched/fair: Improve the accuracy of
sched_stat_wait statistics") fixed a wrong scenairio for cfs schedstat.

This wrong scenario is also present for the RT task. For avoiding this
scenario, add wait_start check in __update_stats_wait_end();

Signed-off-by: Zhang Qiao <zhangqiao22@...wei.com>
---
 kernel/sched/fair.c  |  9 ---------
 kernel/sched/stats.c | 11 ++++++++++-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6a16129f9a5c..36c81fe0086b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1208,15 +1208,6 @@ update_stats_wait_end_fair(struct cfs_rq *cfs_rq, struct sched_entity *se)
 
 	stats = __schedstats_from_se(se);
 
-	/*
-	 * When the sched_schedstat changes from 0 to 1, some sched se
-	 * maybe already in the runqueue, the se->statistics.wait_start
-	 * will be 0.So it will let the delta wrong. We need to avoid this
-	 * scenario.
-	 */
-	if (unlikely(!schedstat_val(stats->wait_start)))
-		return;
-
 	if (entity_is_task(se))
 		p = task_of(se);
 
diff --git a/kernel/sched/stats.c b/kernel/sched/stats.c
index 857f837f52cb..7077eb490c09 100644
--- a/kernel/sched/stats.c
+++ b/kernel/sched/stats.c
@@ -20,8 +20,17 @@ void __update_stats_wait_start(struct rq *rq, struct task_struct *p,
 void __update_stats_wait_end(struct rq *rq, struct task_struct *p,
 			     struct sched_statistics *stats)
 {
-	u64 delta = rq_clock(rq) - schedstat_val(stats->wait_start);
+	u64 delta;
 
+	/*
+	 * When the sched_schedstat changes from 0 to 1, some sched se
+	 * maybe already in the runqueue, the stats->wait_start will be 0.
+	 * So it will let the delta wrong. We need to avoid this scenario.
+	 */
+	if (unlikely(!schedstat_val(stats->wait_start)))
+		return;
+
+	delta = rq_clock(rq) - schedstat_val(stats->wait_start);
 	if (p) {
 		if (task_on_rq_migrating(p)) {
 			/*
-- 
2.18.0.huawei.25