[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce15c757-2983-4360-a0af-e33b8c64da19@amperemail.onmicrosoft.com>
Date: Tue, 25 Nov 2025 16:59:26 +0800
From: Shijie Huang <shijie@...eremail.onmicrosoft.com>
To: Madadi Vineeth Reddy <vineethr@...ux.ibm.com>,
Huang Shijie <shijie@...amperecomputing.com>
Cc: 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 15:08, Madadi Vineeth Reddy wrote:
> I traced the activate_task() call paths and found that load balancing migrations
> through attach_task() in kernel/sched/fair.c may not be covered.
thanks for pointing this, I did not notice them.
>
> activate_task <- attach_task <- attach_tasks <- sched_balance_rq
> activate_task <- attach_task <- attach_one_task <- active_load_balance_cpu_stop
>
> These paths are called in periodic load balancing and when tasks are pulled
> towards an idle CPU via attach_task(), it doesn't update rq->avg_idle or clear
> idle_stamp.
Yes, we should update the rq->avg_idle for them.
I will add it in version 2.
>
> Should attach_task() in kernel/sched/fair.c also call update_rq_avg_idle()
> after activation?
IMHO, we should not call the update_rq_avg_idle() directly in
attach_task().
In the current attach_task(), there is no information for the
context(newidle, idle, busy).
The attach_task() is also called in the newidle code path.
But we can call the update_rq_avg_idle() in attach_tasks() with a
condition check.
>
> Also, can update_rq_avg_idle() be placed inside activate_task() to avoid
> all these?
The same reason as above.
Thanks
Huang Shijie
Powered by blists - more mailing lists