Re: [PATCH] sched/fair: Fix pelt lost idle time detection

[Vincent Guittot <vincent.guittot@linaro.org>]

Le vendredi 16 janv. 2026 à 15:21:35 (+0100), Vincent Guittot a écrit :
> Hi Alex,
> 
> Le vendredi 16 janv. 2026 à 06:51:03 (+0000), Alex Hoh (賀振坤) a écrit :
> > On Sat, 2025-12-13 at 04:54 +0100, Vincent Guittot wrote:
> > > Hi Samuel,
> > > 
> > > 
> > > On Sat, 6 Dec 2025 at 02:20, Samuel Wu <wusamuel@google.com> wrote:
> > > > 
> > > > On Fri, Dec 5, 2025 at 4:54 PM Samuel Wu <wusamuel@google.com>
> > > > wrote:
> > > > > 
> > > > > On Fri, Dec 5, 2025 at 7:08 AM Vincent Guittot
> > > > > <vincent.guittot@linaro.org> wrote:
> > > > > > 
> > > > > > On Tue, 2 Dec 2025 at 01:24, Samuel Wu <wusamuel@google.com>
> > > > > > wrote:
> > > > > > > 
> > > > > > > On Wed, Oct 8, 2025 at 6:12 AM Vincent Guittot
> > > > > > > <vincent.guittot@linaro.org> wrote:
> > > 
> > > [...]
> > > 

[..]

> > > that
> > > were used to decay the util_avg of cfs task before migrating them
> > > which would ends up with decaying too much util_avg
> > > 
> > > But I noticed that you put the util_avg_rt which doesn't use the 2
> > > fields above in mainline. Does android kernel make some changes for
> > > rt
> > > util_avg tracking ?
> > 
> > 
> > I believe this change can indeed account for the observed increase in
> > RT util.
> > 
> > When prev is the last RT task on the rq, the scheduler proceeds through
> > the CFS pick-next flow. With this patch, that path advances
> > rq_clock_pelt to the current time. However, updating rq_clock_pelt at
> > this stage does not seem correct, as RT util has not yet been updated.
> 
> You're right, put prev happens after we updated pelt clock
> 
> Samuel,
> 
> Could you try the fix below ?

I have been too quick and the correct fix should be:

---
 kernel/sched/fair.c | 6 ------
 kernel/sched/idle.c | 2 ++
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 108213e94158..bea71564d3da 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8989,12 +8989,6 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
 			goto again;
 	}

-	/*
-	 * rq is about to be idle, check if we need to update the
-	 * lost_idle_time of clock_pelt
-	 */
-	update_idle_rq_clock_pelt(rq);
-
 	return NULL;
 }

diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 65eb8f8c1a5d..9df6654ef84f 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -468,6 +468,8 @@ static void set_next_task_idle(struct rq *rq, struct task_struct *next, bool fir
 	scx_update_idle(rq, true, true);
 	schedstat_inc(rq->sched_goidle);
 	next->se.exec_start = rq_clock_task(rq);
+
+	update_idle_rq_clock_pelt(rq);
 }

 struct task_struct *pick_task_idle(struct rq *rq, struct rq_flags *rf)
--
2.43.0

> > 
> > The RT util update actually occurs later in put_prev_set_next_task(),
> > and it relies on the original value of rq_clock_pelt as input. Since
> > rq_clock_pelt has already been overwritten by the time the RT util
> > update takes place, the original timestamp is lost.
> > 
> > As a result, the intended CPU/frequency capacity scaling behavior is
> > disrupted, causing RT util to increase more rapidly than expected. This
> > appears to be an unintended consequence introduced by the patch.
> > 
> > > 
> > > > 
> > > > - with patch:
> > > > https://ui.perfetto.dev/#!/?s=964594d07a5a5ba51a159ba6c90bb7ab48e09326
> > > > - without patch:
> > > > https://ui.perfetto.dev/#!/?s=6ff6854c87ea187e4ca488acd2e6501b90ec9f6f