linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Pierre Gondois <Pierre.Gondois@arm.com>
Cc: Ionela Voinescu <Ionela.Voinescu@arm.com>,
	Lukasz Luba <Lukasz.Luba@arm.com>,
	Morten Rasmussen <Morten.Rasmussen@arm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dietmar Eggemann <Dietmar.Eggemann@arm.com>
Subject: Re: [PATCH v1] cpufreq: CPPC: Fix performance/frequency conversion
Date: Fri, 5 Nov 2021 16:40:24 +0100	[thread overview]
Message-ID: <CAJZ5v0g4RrpnRfTsBm_Qi2-JM8SQCAH9_7gTM9cB3Rmc0DG4Hg@mail.gmail.com> (raw)
In-Reply-To: <20211022075057.10759-1-Pierre.Gondois@arm.com>

On Fri, Oct 22, 2021 at 9:51 AM Pierre Gondois <Pierre.Gondois@arm.com> wrote:
>
> CPUfreq governors request CPU frequencies using information
> on current CPU usage. The CPPC driver converts them to
> performance requests. Frequency targets are computed as:
>   target_freq = (util / cpu_capacity) * max_freq
> target_freq is then clamped between [policy->min, policy->max].
>
> The CPPC driver converts performance values to frequencies
> (and vice-versa) using cppc_cpufreq_perf_to_khz() and
> cppc_cpufreq_khz_to_perf(). These functions both use two different
> factors depending on the range of the input value. For
> cppc_cpufreq_khz_to_perf():
> - (NOMINAL_PERF / NOMINAL_FREQ) or
> - (LOWEST_PERF / LOWEST_FREQ)
> and for cppc_cpufreq_perf_to_khz():
> - (NOMINAL_FREQ / NOMINAL_PERF) or
> - ((NOMINAL_PERF - LOWEST_FREQ) / (NOMINAL_PERF - LOWEST_PERF))
>
> This means the functions are not inverse for some values:
> (perf_to_khz(khz_to_perf(x)) != x)
>
> This patch makes use of one single conversion factor, being
> (MAX_PERF / MAX_FREQ).
>
> As LOWEST_FREQ is not used during conversion, the LOWEST_FREQ
> advertised through policy->cpuinfo.min_freq might be different
> from the LOWEST_FREQ value available in the CPPC object,
> but the conversion will be correct.

Well, this assumes that there is a linear perf <-> freq mapping which
is a change in behavior.

While I agree that consistency is a good thing in general, won't this
cause the values visible via sysfs to change?  And if it does, won't
it confuse anyone or break anything in user space?

> Suggested-by: Lukasz Luba <lukasz.luba@arm.com>
> Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com>
> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
> ---
>  drivers/cpufreq/cppc_cpufreq.c | 33 ++++++++++-----------------------
>  1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index d4c27022b9c9..d2ac74e7701e 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -302,13 +302,10 @@ static u64 cppc_get_dmi_max_khz(void)
>  }
>
>  /*
> - * If CPPC lowest_freq and nominal_freq registers are exposed then we can
> - * use them to convert perf to freq and vice versa
> - *
> - * If the perf/freq point lies between Nominal and Lowest, we can treat
> - * (Low perf, Low freq) and (Nom Perf, Nom freq) as 2D co-ordinates of a line
> - * and extrapolate the rest
> - * For perf/freq > Nominal, we use the ratio perf:freq at Nominal for conversion
> + * The CPPC driver receives frequency requests and translates them to performance
> + * requests. Thus, frequency values are actually performance values on a frequency
> + * scale. The conversion is done as:
> + * target_freq = target_perf * (nominal_freq / nominal_perf)
>   */
>  static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu_data,
>                                              unsigned int perf)
> @@ -317,14 +314,9 @@ static unsigned int cppc_cpufreq_perf_to_khz(struct cppc_cpudata *cpu_data,
>         static u64 max_khz;
>         u64 mul, div;
>
> -       if (caps->lowest_freq && caps->nominal_freq) {
> -               if (perf >= caps->nominal_perf) {
> -                       mul = caps->nominal_freq;
> -                       div = caps->nominal_perf;
> -               } else {
> -                       mul = caps->nominal_freq - caps->lowest_freq;
> -                       div = caps->nominal_perf - caps->lowest_perf;
> -               }
> +       if (caps->nominal_freq) {
> +               mul = caps->nominal_freq;
> +               div = caps->nominal_perf;
>         } else {
>                 if (!max_khz)
>                         max_khz = cppc_get_dmi_max_khz();
> @@ -341,14 +333,9 @@ static unsigned int cppc_cpufreq_khz_to_perf(struct cppc_cpudata *cpu_data,
>         static u64 max_khz;
>         u64  mul, div;
>
> -       if (caps->lowest_freq && caps->nominal_freq) {
> -               if (freq >= caps->nominal_freq) {
> -                       mul = caps->nominal_perf;
> -                       div = caps->nominal_freq;
> -               } else {
> -                       mul = caps->lowest_perf;
> -                       div = caps->lowest_freq;
> -               }
> +       if (caps->nominal_freq) {
> +               mul = caps->nominal_perf;
> +               div = caps->nominal_freq;
>         } else {
>                 if (!max_khz)
>                         max_khz = cppc_get_dmi_max_khz();
> --
> 2.17.1
>

  reply	other threads:[~2021-11-05 15:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22  7:50 [PATCH v1] cpufreq: CPPC: Fix performance/frequency conversion Pierre Gondois
2021-11-05 15:40 ` Rafael J. Wysocki [this message]
2021-11-15 10:19   ` Pierre Gondois
2021-11-16 17:53     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJZ5v0g4RrpnRfTsBm_Qi2-JM8SQCAH9_7gTM9cB3Rmc0DG4Hg@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=Ionela.Voinescu@arm.com \
    --cc=Lukasz.Luba@arm.com \
    --cc=Morten.Rasmussen@arm.com \
    --cc=Pierre.Gondois@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).