lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ