Received-SPF: pass (google.com: domain of linux-kernel+bounces-3886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
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 v1] sched/rt: Fix rt task's sched latency statistics in sched_stat_wait trace_point
Date: Mon, 18 Dec 2023 15:03:22 +0000
Message-Id: <20231218150322.788382-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. I found the reason is 
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>
---
 kernel/sched/rt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 6aaf0a3d6081..c75215947c20 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1360,12 +1360,15 @@ 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);
+	if (p != rq->curr)
+		update_stats_wait_end_rt(rt_rq, rt_se);
 
 	if ((flags & DEQUEUE_SLEEP) && p) {
 		unsigned int state;
-- 
2.34.1