[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c1eed8f-455f-4612-be4e-02876f35e37e@arm.com>
Date: Tue, 26 Mar 2024 16:11:31 +0100
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>, Ingo Molnar <mingo@...nel.org>
Cc: peterz@...radead.org, vincent.guittot@...aro.org, qyousef@...alina.io,
linux-kernel@...r.kernel.org, vschneid@...hat.com, joshdon@...gle.com,
riel@...riel.com
Subject: Re: [PATCH] sched/fair: Simplify continue_balancing for newidle
On 26/03/2024 10:00, Shrikanth Hegde wrote:
>
> On 3/26/24 1:37 PM, Ingo Molnar wrote:
>>
>> * Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:
>>
[...]
>> Is this actually true? Any change to behavior invalidates such a sentence.
>
> From what i think, code path is same and I don't see any functionality changing.
> Correct me if i am wrong.
>
> Currently, sched_balance_newidle does the same check to bail out as the
> should_we_balance check in case of newidle. i.e
>
> should_we_balance
> if (env->dst_rq->nr_running > 0 || env->dst_rq->ttwu_pending)
> return 0;
>
> sched_balance_newidle
> if (pulled_task || this_rq->nr_running > 0 ||
> this_rq->ttwu_pending)
> break;
> }
LGTM. Commit 792b9f65a568 ("sched: Allow newidle balancing to bail out
of load_balance") (Jun 22) made sure that we leave sched_balance_rq()
(former load_balance()) for CPU_NEWLY_IDLE asap to reduce wakeup latency.
So IMHO, we can use 'continue_balancing' instead of 'this_rq->nr_running
> 0 || this_rq->ttwu_pending' in sched_balance_newidle() (former
newidle_balance()).
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@....com>
Powered by blists - more mailing lists