linux-kernel - Re: [PATCH v5 0/2] sched: update the rq->avg_idle when a task is moved to an idle CPU

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] [day] [month] [year] [list]

Message-ID: <7dc08b7f-00d3-440e-860c-5b90ccebc0bb@amperemail.onmicrosoft.com>
Date: Fri, 5 Dec 2025 10:09:38 +0800
From: Shijie Huang <shijie@...eremail.onmicrosoft.com>
To: Dietmar Eggemann <dietmar.eggemann@....com>,
 Huang Shijie <shijie@...amperecomputing.com>, mingo@...hat.com,
 peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org
Cc: patches@...erecomputing.com, cl@...ux.com,
 Shubhang@...amperecomputing.com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, linux-kernel@...r.kernel.org, vschneid@...hat.com,
 vineethr@...ux.ibm.com, kprateek.nayak@....com
Subject: Re: [PATCH v5 0/2] sched: update the rq->avg_idle when a task is
 moved to an idle CPU


On 04/12/2025 21:09, Dietmar Eggemann wrote:
> On 03.12.25 06:30, Huang Shijie wrote:
>> In the newidle balance, the rq->idle_stamp may set to a non-zero value
>> if it cannot pull any task.
>>
>> In the wakeup, it will detect the rq->idle_stamp, and updates
>> the rq->avg_idle, then ends the CPU idle status by setting rq->idle_stamp
>> to zero.
>>
>> Besides the wakeup, current code does not end the CPU idle status
>> when a task is moved to the idle CPU, such as fork/clone, execve,
>> or other cases.
> Is there a case which is the most important one? (e.g. idle load balancing)?
>
> I still can't see the reason why this code should be changed (was asked
> in v4 already).

I noticed that the rq->idle_stamp is not zero when rq->idle_stamp is set in

begining of sched_balance_newidle(). It is a strange behavior.

then I found a new task(clone/fork, etc) may be move to this rq while 
this rq->idle_stamp

is still not zero. it triggers the second newidle on this CPU.


>
> Do you have a workload on your machine which gives you better scores in
> case you set 'rq->idle_stamp = 0' in all those cases?

I tested the specjbb, the performance does not change.

Btw, the "rq->idle_stamp = 0" is redandent, we can remove it in patch 1.


> What is is actual issue in the current code?

the current code is confusing to me :)

Current  rq->idle_stamp is equal to rq->wakeup_idle_stamp.


>
> Does 'this_rq->avg_idle' get too big so you spend too much useless time
> (since pulled_task == 0) in sched_balance_newidle() because the bailout
> condition:
>
> sched_balance_newidle()
>
>    ...
>    if (!get_rd_overloaded(this_rq->rd) ||
>        this_rq->avg_idle < sd->max_newidle_lb_cost) {
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>      ...
>      goto out;
>
> doesn't trigger anymore?

Not this issue.


Thanks

Huang Shijie

>
> [...]