[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d2ac3963-9c91-4256-a1e3-ea5990848c1e@arm.com>
Date: Wed, 18 Oct 2023 10:16:21 +0100
From: Lukasz Luba <lukasz.luba@....com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: dietmar.eggemann@....com, bristot@...hat.com,
aou@...s.berkeley.edu, palmer@...belt.com,
paul.walmsley@...ive.com, conor.dooley@...rochip.com,
rostedt@...dmis.org, juri.lelli@...hat.com,
viresh.kumar@...aro.org, suagrfillet@...il.com,
linux-pm@...r.kernel.org, ionela.voinescu@....com,
vschneid@...hat.com, ajones@...tanamicro.com,
catalin.marinas@....com, linux@...linux.org.uk,
linux-riscv@...ts.infradead.org, pierre.gondois@....com,
lftan@...nel.org, linux-kernel@...r.kernel.org, bsegall@...gle.com,
mingo@...hat.com, rafael@...nel.org,
linux-arm-kernel@...ts.infradead.org, peterz@...radead.org,
gregkh@...uxfoundation.org, mgorman@...e.de, will@...nel.org,
sudeep.holla@....com
Subject: Re: [PATCH v2 5/6] energy_model: use a fixed reference frequency
Hi Vincent,
On 10/9/23 11:36, Vincent Guittot wrote:
> The last item of a performance domain is not always the performance point
> that has been used to compute CPU's capacity. This can lead to different
> target frequency compared with other part of the system like schedutil and
> would result in wrong energy estimation.
>
> A new arch_scale_freq_ref() is available to return a fixed and coherent
> frequency reference that can be used when computing the CPU's frequency
> for an level of utilization. Use this function to get this reference
> frequency.
>
> Energy model is never used without defining arch_scale_freq_ref() but
> can be compiled. Define a default arch_scale_freq_ref() returning 0
> in such case.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> ---
> include/linux/energy_model.h | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
LGTM, taking into account the patch 2/6 that we don't include any
boost freq (so no changes w.r.t. current EAS situation)
Reviewed-by: Lukasz Luba <lukasz.luba@....com>
Powered by blists - more mailing lists