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

[Shijie Huang]

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

> [...]