[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26af2033-c5e0-43a1-8953-35435ffbbdd0@arm.com>
Date: Thu, 29 Feb 2024 10:11:09 +0100
From: Pierre Gondois <pierre.gondois@....com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: yu.c.chen@...el.com, dietmar.eggemann@....com,
linux-kernel@...r.kernel.org, nysal@...ux.ibm.com, aboorvad@...ux.ibm.com,
srikar@...ux.vnet.ibm.com, vschneid@...hat.com, morten.rasmussen@....com,
qyousef@...alina.io, mingo@...nel.org, peterz@...radead.org,
vincent.guittot@...aro.org
Subject: Re: [PATCH v2 1/2] sched/fair: Add EAS checks before updating
overutilized
Hello Shrikanth,
On 2/28/24 18:24, Shrikanth Hegde wrote:
>
>
> On 2/28/24 9:28 PM, Pierre Gondois wrote:
>
> Hi Pierre, Thanks for taking a look.
>
>> It is nice to avoid calling effective_cpu_util() through the following
>> when EAS is not enabled:
>> I think we are avoiding calling cpu_overutilized except in update_sg_lb_stats.
> I didnt want to put a EAS check in cpu_overutilized as it could be useful
> function in non-EAS cases in future. calling cpu_overutilized alone doesnt
> do any access to root_domain's overutilized field. So we are okay w.r.t to
> cache issues.
> But we will do some extra computation currently and then not use it if it
> Non-EAS case in update_sg_lb_stats
>
> Would something like this makes sense?
> @@ -9925,7 +9925,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
> if (nr_running > 1)
> *sg_status |= SG_OVERLOAD;
>
> - if (cpu_overutilized(i))
> + if (sched_energy_enabled() && cpu_overutilized(i))
> *sg_status |= SG_OVERUTILIZED;
>
Yes right. I think that what Dietmar suggested is also a good idea
which could be used instead.
>
>
>
> I didnt find how would util_fits_cpu ends up calling effective_cpu_util.
> Could you please elaborate?
Sorry I meant this path:
cpu_overutilized()
\-cpu_util_cfs()
\-cpu_util()
effective_cpu_util() is effectively not involved.
>
>> cpu_overutilized()
>> \-util_fits_cpu()
>> \- ...
>> \-effective_cpu_util()
>>
[snip]
Regards,
Pierre
Powered by blists - more mailing lists