[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <65e7519d-03a3-4c43-a9aa-fcd578b78c31@amperemail.onmicrosoft.com>
Date: Wed, 26 Nov 2025 10:14:29 +0800
From: Shijie Huang <shijie@...eremail.onmicrosoft.com>
To: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>
Cc: Huang Shijie <shijie@...amperecomputing.com>, mingo@...hat.com,
peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org,
patches@...erecomputing.com, cl@...ux.com, Shubhang@...amperecomputing.com,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, linux-kernel@...r.kernel.org, vschneid@...hat.com
Subject: Re: [PATCH] sched: update the rq->avg_idle when a task is moved to an
idle CPU
On 25/11/2025 18:02, Madadi Vineeth Reddy wrote:
> IIUC, update_rq_avg_idle() already checks if (rq->idle_stamp) internally and
> in attach_task() we have rq available and the guard in update_rq_avg_idle()
> ensures we only update when the CPU was actually idle. Whether it's called
> during newidle, idle, or busy balancing shouldn't matter.
In the newidle function:
sched_balance_newidle():
...............................
this_rq->idle_stamp = rq_clock(this_rq); // step 1
sched_balance_rq() ---> ... --> attach_task() // step 2
if (pulled_task)
this_rq->idle_stamp = 0; // step 3
.............................................
If update_rq_avg_idle() is called in attach_task() in "step
2", it will mess up the "step 1".
The update_rq_avg_idle() should be called after "step 3".
Thanks
Huang Shijie
Powered by blists - more mailing lists