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

[Alex Hoh (賀振坤)]

On Fri, 2026-01-16 at 17:13 +0100, Vincent Guittot wrote:
> 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@xxxxxxxxxx>
> > > > wrote:
> > > > > 
> > > > > On Fri, Dec 5, 2025 at 4:54 PM Samuel Wu
> > > > > <wusamuel@xxxxxxxxxx>
> > > > > wrote:
> > > > > > 
> > > > > > On Fri, Dec 5, 2025 at 7:08 AM Vincent Guittot
> > > > > > <vincent.guittot@xxxxxxxxxx> wrote:
> > > > > > > 
> > > > > > > On Tue, 2 Dec 2025 at 01:24, Samuel Wu
> > > > > > > <wusamuel@xxxxxxxxxx>
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > On Wed, Oct 8, 2025 at 6:12 AM Vincent Guittot
> > > > > > > > <vincent.guittot@xxxxxxxxxx> 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
> 

This fix looks good to me, and in my local testing, 
RT utilization dropped significantly from 72 to 20.

> > > 
> > > 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://urldefense.com/v3/__https://ui.perfetto.dev/*!/?s=964594d07a5a5ba51a159ba6c90bb7ab48e09326__;Iw!!CTRNKA9wMg0ARbw!hSdr5foMTuMuY9OK82IumAY3LPDt5HCKhkduyW-8UsLaQvcW8F-kwwsgcX0crwnkzU29xvN24l5bpsa55oqTy5MwyJxI$
> > > > >  
> > > > > - without patch:
> > > > > https://urldefense.com/v3/__https://ui.perfetto.dev/*!/?s=6ff6854c87ea187e4ca488acd2e6501b90ec9f6f__;Iw!!CTRNKA9wMg0ARbw!hSdr5foMTuMuY9OK82IumAY3LPDt5HCKhkduyW-8UsLaQvcW8F-kwwsgcX0crwnkzU29xvN24l5bpsa55oqTyzycmnIs$
> > > > >