From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Giovanni Gherdovich <ggherdovich@suse.cz>
Cc: Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
Jon Grimm <Jon.Grimm@amd.com>,
Nathan Fontenot <Nathan.Fontenot@amd.com>,
Yazen Ghannam <Yazen.Ghannam@amd.com>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
Suthikulpanit Suravee <Suravee.Suthikulpanit@amd.com>,
Mel Gorman <mgorman@techsingularity.net>, Pu Wen <puwen@hygon.cn>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Michael Larabel <Michael@phoronix.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula
Date: Tue, 2 Feb 2021 20:26:16 +0100 [thread overview]
Message-ID: <CAJZ5v0jsF-_8GzQgqZH10bf0oUTmALiT1kVcjDqYgGPqx9iKZg@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0hQ_r3th5upo-X5fNBG0tUNbLbhQN-cqmDd1FGwhGx4dg@mail.gmail.com>
On Tue, Feb 2, 2021 at 7:59 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Jan 22, 2021 at 9:47 PM Giovanni Gherdovich <ggherdovich@suse.cz> wrote:
> >
>
> [cut]
>
> >
> > Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
> > Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC")
> > Reported-by: Michael Larabel <Michael@phoronix.com>
> > Signed-off-by: Giovanni Gherdovich <ggherdovich@suse.cz>
> > ---
> > drivers/cpufreq/acpi-cpufreq.c | 64 +++++++++++++++++++++++++++++++-
> > drivers/cpufreq/cpufreq.c | 3 ++
> > include/linux/cpufreq.h | 5 +++
> > kernel/sched/cpufreq_schedutil.c | 8 +++-
> > 4 files changed, 76 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> > index 1e4fbb002a31..2378bc1bf2c4 100644
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -27,6 +27,10 @@
> >
> > #include <acpi/processor.h>
> >
> > +#ifdef CONFIG_ACPI_CPPC_LIB
>
> Why is the #ifdef needed here?
>
> > +#include <acpi/cppc_acpi.h>
> > +#endif
> > +
> > #include <asm/msr.h>
> > #include <asm/processor.h>
> > #include <asm/cpufeature.h>
> > @@ -628,11 +632,57 @@ static int acpi_cpufreq_blacklist(struct cpuinfo_x86 *c)
> > }
> > #endif
> >
> > +#ifdef CONFIG_ACPI_CPPC_LIB
> > +static bool amd_max_boost(unsigned int max_freq,
> > + unsigned int *max_boost)
> > +{
> > + struct cppc_perf_caps perf_caps;
> > + u64 highest_perf, nominal_perf, perf_ratio;
> > + int ret;
> > +
> > + ret = cppc_get_perf_caps(0, &perf_caps);
> > + if (ret) {
> > + pr_debug("Could not retrieve perf counters (%d)\n", ret);
> > + return false;
> > + }
> > +
> > + highest_perf = perf_caps.highest_perf;
> > + nominal_perf = perf_caps.nominal_perf;
> > +
> > + if (!highest_perf || !nominal_perf) {
> > + pr_debug("Could not retrieve highest or nominal performance\n");
> > + return false;
> > + }
> > +
> > + perf_ratio = div_u64(highest_perf * SCHED_CAPACITY_SCALE, nominal_perf);
> > + if (perf_ratio <= SCHED_CAPACITY_SCALE) {
> > + pr_debug("Either perf_ratio is 0, or nominal >= highest performance\n");
> > + return false;
> > + }
> > +
> > + *max_boost = max_freq * perf_ratio >> SCHED_CAPACITY_SHIFT;
> > + if (!*max_boost) {
> > + pr_debug("max_boost seems to be zero\n");
> > + return false;
> > + }
> > +
> > + return true;
> > +}
> > +#else
> > +static bool amd_max_boost(unsigned int max_freq,
> > + unsigned int *max_boost)
> > +{
> > + return false;
> > +}
> > +#endif
> > +
> > static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
> > {
> > unsigned int i;
> > unsigned int valid_states = 0;
> > unsigned int cpu = policy->cpu;
> > + unsigned int freq, max_freq = 0;
> > + unsigned int max_boost;
> > struct acpi_cpufreq_data *data;
> > unsigned int result = 0;
> > struct cpuinfo_x86 *c = &cpu_data(policy->cpu);
> > @@ -779,15 +829,25 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
> > freq_table[valid_states-1].frequency / 1000)
> > continue;
> >
> > + freq = perf->states[i].core_frequency * 1000;
> > freq_table[valid_states].driver_data = i;
> > - freq_table[valid_states].frequency =
> > - perf->states[i].core_frequency * 1000;
> > + freq_table[valid_states].frequency = freq;
> > +
> > + if (freq > max_freq)
> > + max_freq = freq;
> > +
> > valid_states++;
> > }
> > freq_table[valid_states].frequency = CPUFREQ_TABLE_END;
> > policy->freq_table = freq_table;
> > perf->state = 0;
> >
> > + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
> > + amd_max_boost(max_freq, &max_boost)) {
> > + policy->cpuinfo.max_boost = max_boost;
>
> Why not to set max_freq to max_boost instead?
I mean, would setting the frequency in the last table entry to max_boost work?
Alternatively, one more (artificial) entry with the frequency equal to
max_boost could be added.
> This value is set once at the init time anyway and schedutil would use
> max_boost instead of max_freq anyway.
>
> Also notice that the static branch is global and the max_boost value
> for different CPUs may be different, at least in theory.
>
> > + static_branch_enable(&cpufreq_amd_max_boost);
> > + }
> > +
> > switch (perf->control_register.space_id) {
> > case ACPI_ADR_SPACE_SYSTEM_IO:
> > /*
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index d0a3525ce27f..b96677f6b57e 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2721,6 +2721,9 @@ int cpufreq_boost_enabled(void)
> > }
> > EXPORT_SYMBOL_GPL(cpufreq_boost_enabled);
> >
> > +DEFINE_STATIC_KEY_FALSE(cpufreq_amd_max_boost);
> > +EXPORT_SYMBOL_GPL(cpufreq_amd_max_boost);
> > +
> > /*********************************************************************
> > * REGISTER / UNREGISTER CPUFREQ DRIVER *
> > *********************************************************************/
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index 9c8b7437b6cd..341cac76d254 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -40,9 +40,14 @@ enum cpufreq_table_sorting {
> > CPUFREQ_TABLE_SORTED_DESCENDING
> > };
> >
> > +DECLARE_STATIC_KEY_FALSE(cpufreq_amd_max_boost);
> > +
> > +#define cpufreq_driver_has_max_boost() static_branch_unlikely(&cpufreq_amd_max_boost)
> > +
> > struct cpufreq_cpuinfo {
> > unsigned int max_freq;
> > unsigned int min_freq;
> > + unsigned int max_boost;
> >
> > /* in 10^(-9) s = nanoseconds */
> > unsigned int transition_latency;
> > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> > index 6931f0cdeb80..541f3db3f576 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -159,8 +159,12 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
> > unsigned long util, unsigned long max)
> > {
> > struct cpufreq_policy *policy = sg_policy->policy;
> > - unsigned int freq = arch_scale_freq_invariant() ?
> > - policy->cpuinfo.max_freq : policy->cur;
> > + unsigned int freq, max_freq;
> > +
> > + max_freq = cpufreq_driver_has_max_boost() ?
> > + policy->cpuinfo.max_boost : policy->cpuinfo.max_freq;
> > +
> > + freq = arch_scale_freq_invariant() ? max_freq : policy->cur;
> >
> > freq = map_util_freq(util, freq, max);
> >
> > --
> > 2.26.2
> >
next prev parent reply other threads:[~2021-02-02 19:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-22 20:40 [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Giovanni Gherdovich
2021-01-22 20:40 ` [PATCH v2 1/1] x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant formula Giovanni Gherdovich
2021-01-25 10:04 ` Peter Zijlstra
2021-01-26 9:28 ` Giovanni Gherdovich
2021-01-26 10:02 ` Peter Zijlstra
2021-02-02 18:45 ` Rafael J. Wysocki
2021-02-02 19:11 ` Rafael J. Wysocki
2021-02-03 9:56 ` Giovanni Gherdovich
2021-02-02 18:40 ` Rafael J. Wysocki
2021-01-25 10:06 ` Peter Zijlstra
2021-01-26 9:09 ` Giovanni Gherdovich
2021-01-26 9:31 ` Mel Gorman
2021-01-26 10:05 ` Peter Zijlstra
[not found] ` <1611933781.15858.48.camel@suse.cz>
2021-02-02 14:17 ` Giovanni Gherdovich
2021-02-02 18:21 ` Peter Zijlstra
2021-02-02 18:29 ` Rafael J. Wysocki
2021-02-02 19:00 ` Rafael J. Wysocki
2021-02-02 18:59 ` Rafael J. Wysocki
2021-02-02 19:26 ` Rafael J. Wysocki [this message]
2021-02-03 8:39 ` Giovanni Gherdovich
2021-02-03 13:40 ` Rafael J. Wysocki
2021-02-03 9:12 ` Giovanni Gherdovich
2021-02-03 6:04 ` Viresh Kumar
2021-01-24 22:30 ` [PATCH v2 0/1] AMD EPYC: fix schedutil perf regression (freq-invariance) Michael Larabel
2021-01-25 8:34 ` Peter Zijlstra
2021-01-26 9:01 ` Giovanni Gherdovich
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=CAJZ5v0jsF-_8GzQgqZH10bf0oUTmALiT1kVcjDqYgGPqx9iKZg@mail.gmail.com \
--to=rafael@kernel.org \
--cc=Jon.Grimm@amd.com \
--cc=Michael@phoronix.com \
--cc=Nathan.Fontenot@amd.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Yazen.Ghannam@amd.com \
--cc=bp@alien8.de \
--cc=dietmar.eggemann@arm.com \
--cc=ggherdovich@suse.cz \
--cc=juri.lelli@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=puwen@hygon.cn \
--cc=rjw@rjwysocki.net \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=x86@kernel.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).