Received-SPF: pass (google.com: domain of linux-kernel+bounces-8617-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Junwen Wu <wudaemon@163.com>
To: mingo@redhat.com,
	laoar.shao@gmail.com,
	peterz@infradead.org,
	juri.lelli@redhat.com,
	vincent.guittot@linaro.org,
	dietmar.eggemann@arm.com,
	rostedt@goodmis.org,
	bsegall@google.com
Cc: mgorman@suse.de,
	bristot@redhat.com,
	vschneid@redhat.com,
	linux-kernel@vger.kernel.org,
	Junwen Wu <wudaemon@163.com>
Subject: [PATCH v2] sched/rt: Fix rt task's sched latency statistics error in sched_stat_wait trace_point
Date: Thu, 21 Dec 2023 15:02:38 +0000
Message-Id: <20231221150238.856960-1-wudaemon@163.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

When enable sched_stat_wait trace_point, some rt tasks sched latency
so long, like this:
sched_stat_wait: comm=rcu_preempt pid=14 delay=4936139545261 [ns]
Rt task has low latency, it must have a bug. When rt task balance off
source cpu, dequeue operation not update the sched_statistics, so follow
update_stats_wait_end_fair update method.

Signed-off-by: Junwen Wu <wudaemon@163.com>
---
Changes since v1:
https://lore.kernel.org/all/20231218150322.788382-1-wudaemon@163.com/

 kernel/sched/rt.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 6aaf0a3d6081..6a2600213991 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1360,12 +1360,19 @@ update_stats_dequeue_rt(struct rt_rq *rt_rq, struct sched_rt_entity *rt_se,
 			int flags)
 {
 	struct task_struct *p = NULL;
+	struct rq *rq = rq_of_rt_se(rt_se);
 
 	if (!schedstat_enabled())
 		return;
 
 	if (rt_entity_is_task(rt_se))
 		p = rt_task_of(rt_se);
+	 /*
+	  * Mark the end of the wait period
+	  * if dequeueing a waiting task.
+	  */
+	if (p && (p != rq->curr))
+		update_stats_wait_end_rt(rt_rq, rt_se);
 
 	if ((flags & DEQUEUE_SLEEP) && p) {
 		unsigned int state;
-- 
2.34.1