Some AMD Ryzen generations has different calculation method on maximum
perf. 255 is not for all asics, some specific generations should use 166
as the maximum perf. Otherwise, it will report incorrect frequency value
like below:
~ → lscpu | grep MHz
CPU MHz: 3400.000
CPU max MHz: 7228.3198
CPU min MHz: 2200.0000
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham <[email protected]>
Tested-by: Jason Bagavatsingham <[email protected]>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791
Signed-off-by: Huang Rui <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Nathan Fontenot <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
Changes from V1 -> V2:
- Enhance the commit message.
- Move amd_get_highest_perf() into amd.c.
- Refine the implementation of switch-case.
- Cc stable mail list.
Changes from V2 -> V3:
- Move the update into cppc_get_perf_caps() to correct the highest perf value in
the API.
Changes from V3 -> V4:
- Rollback to V2 implementation because acpi_cppc.c will be used by ARM as well.
It's not good to add x86-specific calling there.
- Simplify the implementation of the functions.
---
arch/x86/include/asm/processor.h | 2 ++
arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++++
arch/x86/kernel/smpboot.c | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 6 +++++-
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index f1b9ed5efaa9..908bcaea1361 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD
extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_highest_perf(void);
#else
static inline u32 amd_get_nodes_per_socket(void) { return 0; }
+static inline u32 amd_get_highest_perf(void) { return 0; }
#endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 347a956f71ca..bc3496669def 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
break;
}
}
+
+u32 amd_get_highest_perf(void)
+{
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+
+ if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
+ (c->x86_model >= 0x70 && c->x86_model < 0x80)))
+ return 166;
+
+ if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
+ (c->x86_model >= 0x40 && c->x86_model < 0x70)))
+ return 166;
+
+ return 225;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 02813a7f3a7c..7bec57d04a87 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -2046,7 +2046,7 @@ static bool amd_set_max_freq_ratio(void)
return false;
}
- highest_perf = perf_caps.highest_perf;
+ highest_perf = amd_get_highest_perf();
nominal_perf = perf_caps.nominal_perf;
if (!highest_perf || !nominal_perf) {
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index d1bbc16fba4b..7e7450453714 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -646,7 +646,11 @@ static u64 get_max_boost_ratio(unsigned int cpu)
return 0;
}
- highest_perf = perf_caps.highest_perf;
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ highest_perf = amd_get_highest_perf();
+ else
+ highest_perf = perf_caps.highest_perf;
+
nominal_perf = perf_caps.nominal_perf;
if (!highest_perf || !nominal_perf) {
--
2.25.1
On Sun, Apr 25, 2021 at 9:35 AM Huang Rui <[email protected]> wrote:
>
> Some AMD Ryzen generations has different calculation method on maximum
> perf. 255 is not for all asics, some specific generations should use 166
> as the maximum perf. Otherwise, it will report incorrect frequency value
> like below:
>
> ~ → lscpu | grep MHz
> CPU MHz: 3400.000
> CPU max MHz: 7228.3198
> CPU min MHz: 2200.0000
>
> Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
> Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
>
> Reported-by: Jason Bagavatsingham <[email protected]>
> Tested-by: Jason Bagavatsingham <[email protected]>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791
> Signed-off-by: Huang Rui <[email protected]>
> Cc: Alex Deucher <[email protected]>
> Cc: Nathan Fontenot <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
>
> Changes from V1 -> V2:
> - Enhance the commit message.
> - Move amd_get_highest_perf() into amd.c.
> - Refine the implementation of switch-case.
> - Cc stable mail list.
>
> Changes from V2 -> V3:
> - Move the update into cppc_get_perf_caps() to correct the highest perf value in
> the API.
>
> Changes from V3 -> V4:
> - Rollback to V2 implementation because acpi_cppc.c will be used by ARM as well.
> It's not good to add x86-specific calling there.
> - Simplify the implementation of the functions.
All of my comments have been addressed, so:
Reviewed-by: Rafael J. Wysocki <[email protected]>
and I'm expecting the x86 maintainers to take care of this patch.
> ---
> arch/x86/include/asm/processor.h | 2 ++
> arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++++
> arch/x86/kernel/smpboot.c | 2 +-
> drivers/cpufreq/acpi-cpufreq.c | 6 +++++-
> 4 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index f1b9ed5efaa9..908bcaea1361 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
>
> #ifdef CONFIG_CPU_SUP_AMD
> extern u32 amd_get_nodes_per_socket(void);
> +extern u32 amd_get_highest_perf(void);
> #else
> static inline u32 amd_get_nodes_per_socket(void) { return 0; }
> +static inline u32 amd_get_highest_perf(void) { return 0; }
> #endif
>
> static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 347a956f71ca..bc3496669def 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> break;
> }
> }
> +
> +u32 amd_get_highest_perf(void)
> +{
> + struct cpuinfo_x86 *c = &boot_cpu_data;
> +
> + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> + return 166;
> +
> + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> + return 166;
> +
> + return 225;
> +}
> +EXPORT_SYMBOL_GPL(amd_get_highest_perf);
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 02813a7f3a7c..7bec57d04a87 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -2046,7 +2046,7 @@ static bool amd_set_max_freq_ratio(void)
> return false;
> }
>
> - highest_perf = perf_caps.highest_perf;
> + highest_perf = amd_get_highest_perf();
> nominal_perf = perf_caps.nominal_perf;
>
> if (!highest_perf || !nominal_perf) {
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index d1bbc16fba4b..7e7450453714 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -646,7 +646,11 @@ static u64 get_max_boost_ratio(unsigned int cpu)
> return 0;
> }
>
> - highest_perf = perf_caps.highest_perf;
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
> + highest_perf = amd_get_highest_perf();
> + else
> + highest_perf = perf_caps.highest_perf;
> +
> nominal_perf = perf_caps.nominal_perf;
>
> if (!highest_perf || !nominal_perf) {
> --
> 2.25.1
>
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 337fb3130c29ef5ea3bbcd45e6589b7be6deeb4d
Gitweb: https://git.kernel.org/tip/337fb3130c29ef5ea3bbcd45e6589b7be6deeb4d
Author: Huang Rui <[email protected]>
AuthorDate: Sun, 25 Apr 2021 15:34:51 +08:00
Committer: Ingo Molnar <[email protected]>
CommitterDate: Wed, 12 May 2021 21:14:08 +02:00
x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations
Some AMD Ryzen generations has different calculation method on maximum
performance. 255 is not for all ASICs, some specific generations should use 166
as the maximum performance. Otherwise, it will report incorrect frequency value
like below:
~ → lscpu | grep MHz
CPU MHz: 3400.000
CPU max MHz: 7228.3198
CPU min MHz: 2200.0000
[ mingo: Tidied up whitespace use. ]
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Huang Rui <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Jason Bagavatsingham <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791
---
arch/x86/include/asm/processor.h | 2 ++
arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++++
arch/x86/kernel/smpboot.c | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 6 +++++-
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 154321d..556b2b1 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -787,8 +787,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD
extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_highest_perf(void);
#else
static inline u32 amd_get_nodes_per_socket(void) { return 0; }
+static inline u32 amd_get_highest_perf(void) { return 0; }
#endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 2d11384..109d2c7 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1165,3 +1165,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
break;
}
}
+
+u32 amd_get_highest_perf(void)
+{
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+
+ if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
+ (c->x86_model >= 0x70 && c->x86_model < 0x80)))
+ return 166;
+
+ if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
+ (c->x86_model >= 0x40 && c->x86_model < 0x70)))
+ return 166;
+
+ return 225;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 0ad5214..7770245 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -2043,7 +2043,7 @@ static bool amd_set_max_freq_ratio(void)
return false;
}
- highest_perf = perf_caps.highest_perf;
+ highest_perf = amd_get_highest_perf();
nominal_perf = perf_caps.nominal_perf;
if (!highest_perf || !nominal_perf) {
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index d1bbc16..7e74504 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -646,7 +646,11 @@ static u64 get_max_boost_ratio(unsigned int cpu)
return 0;
}
- highest_perf = perf_caps.highest_perf;
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ highest_perf = amd_get_highest_perf();
+ else
+ highest_perf = perf_caps.highest_perf;
+
nominal_perf = perf_caps.nominal_perf;
if (!highest_perf || !nominal_perf) {
* Huang Rui <[email protected]> wrote:
> Some AMD Ryzen generations has different calculation method on maximum
> perf. 255 is not for all asics, some specific generations should use 166
> as the maximum perf. Otherwise, it will report incorrect frequency value
> like below:
>
> ~ → lscpu | grep MHz
> CPU MHz: 3400.000
> CPU max MHz: 7228.3198
> CPU min MHz: 2200.0000
It would have been useful to also quote the 'after' part.
> +u32 amd_get_highest_perf(void)
> +{
> + struct cpuinfo_x86 *c = &boot_cpu_data;
> +
> + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> + return 166;
> +
> + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> + return 166;
I fixed these stray 4-space tabs.
Looks good otherwise - queued up in tip:sched/urgent.
Thanks,
Ingo
On Sun, 25 Apr 2021, Huang Rui wrote:
> Some AMD Ryzen generations has different calculation method on maximum
> perf. 255 is not for all asics, some specific generations should use 166
> as the maximum perf. Otherwise, it will report incorrect frequency value
> like below:
The commit message says '255', but the code:
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> break;
> }
> }
> +
> +u32 amd_get_highest_perf(void)
> +{
> + struct cpuinfo_x86 *c = &boot_cpu_data;
> +
> + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> + return 166;
> +
> + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> + return 166;
> +
> + return 225;
> +}
says 225? This is probably a typo? In any case they are out of sync.
Alexander
* Alexander Monakov <[email protected]> wrote:
> On Sun, 25 Apr 2021, Huang Rui wrote:
>
> > Some AMD Ryzen generations has different calculation method on maximum
> > perf. 255 is not for all asics, some specific generations should use 166
> > as the maximum perf. Otherwise, it will report incorrect frequency value
> > like below:
>
> The commit message says '255', but the code:
>
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> > break;
> > }
> > }
> > +
> > +u32 amd_get_highest_perf(void)
> > +{
> > + struct cpuinfo_x86 *c = &boot_cpu_data;
> > +
> > + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> > + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> > + return 166;
> > +
> > + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> > + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> > + return 166;
> > +
> > + return 225;
> > +}
>
> says 225? This is probably a typo? In any case they are out of sync.
>
> Alexander
Ugh - that's indeed a good question ...
Thanks,
Ingo
On Thu, May 13, 2021 at 06:59:02AM +0800, Ingo Molnar wrote:
>
> * Alexander Monakov <[email protected]> wrote:
>
> > On Sun, 25 Apr 2021, Huang Rui wrote:
> >
> > > Some AMD Ryzen generations has different calculation method on maximum
> > > perf. 255 is not for all asics, some specific generations should use 166
> > > as the maximum perf. Otherwise, it will report incorrect frequency value
> > > like below:
> >
> > The commit message says '255', but the code:
> >
> > > --- a/arch/x86/kernel/cpu/amd.c
> > > +++ b/arch/x86/kernel/cpu/amd.c
> > > @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> > > break;
> > > }
> > > }
> > > +
> > > +u32 amd_get_highest_perf(void)
> > > +{
> > > + struct cpuinfo_x86 *c = &boot_cpu_data;
> > > +
> > > + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> > > + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> > > + return 166;
> > > +
> > > + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> > > + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> > > + return 166;
> > > +
> > > + return 225;
> > > +}
> >
> > says 225? This is probably a typo? In any case they are out of sync.
> >
> > Alexander
>
> Ugh - that's indeed a good question ...
>
Ah sorry! It's my typo. It should be 255 (confirmed in the ucode).
Alexander, thanks a lot to catch this!
Ingo, would you mind to update it from 225 -> 255 while you apply this
patch or let me know if you want me to send v5?
Thanks,
Ray
* Huang Rui <[email protected]> wrote:
> On Thu, May 13, 2021 at 06:59:02AM +0800, Ingo Molnar wrote:
> >
> > * Alexander Monakov <[email protected]> wrote:
> >
> > > On Sun, 25 Apr 2021, Huang Rui wrote:
> > >
> > > > Some AMD Ryzen generations has different calculation method on maximum
> > > > perf. 255 is not for all asics, some specific generations should use 166
> > > > as the maximum perf. Otherwise, it will report incorrect frequency value
> > > > like below:
> > >
> > > The commit message says '255', but the code:
> > >
> > > > --- a/arch/x86/kernel/cpu/amd.c
> > > > +++ b/arch/x86/kernel/cpu/amd.c
> > > > @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> > > > break;
> > > > }
> > > > }
> > > > +
> > > > +u32 amd_get_highest_perf(void)
> > > > +{
> > > > + struct cpuinfo_x86 *c = &boot_cpu_data;
> > > > +
> > > > + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> > > > + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> > > > + return 166;
> > > > +
> > > > + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> > > > + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> > > > + return 166;
> > > > +
> > > > + return 225;
> > > > +}
> > >
> > > says 225? This is probably a typo? In any case they are out of sync.
> > >
> > > Alexander
> >
> > Ugh - that's indeed a good question ...
> >
>
> Ah sorry! It's my typo. It should be 255 (confirmed in the ucode).
>
> Alexander, thanks a lot to catch this!
>
> Ingo, would you mind to update it from 225 -> 255 while you apply this
> patch or let me know if you want me to send v5?
No need to send v5, done!
I have a system that appears to be affected by this bug:
kepler:~> lscpu | grep -i mhz
CPU MHz: 4000.000
CPU max MHz: 7140.6250
CPU min MHz: 2200.0000
So I should be able to confirm after a reboot.
Thanks,
Ingo
On Thu, May 13, 2021 at 06:39:08PM +0800, Ingo Molnar wrote:
>
> * Ingo Molnar <[email protected]> wrote:
>
> > No need to send v5, done!
> >
> > I have a system that appears to be affected by this bug:
> >
> > kepler:~> lscpu | grep -i mhz
> > CPU MHz: 4000.000
> > CPU max MHz: 7140.6250
> > CPU min MHz: 2200.0000
> >
> > So I should be able to confirm after a reboot.
>
> 'CPU max Mhz' seems to be saner now:
>
> kepler:~> lscpu | grep -i mhz
>
> CPU MHz: 2200.000
> CPU max MHz: 4917.9678
> CPU min MHz: 2200.0000
>
Yes, happy to know this :-)
Thanks,
Ray
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 3743d55b289c203d8f77b7cd47c24926b9d186ae
Gitweb: https://git.kernel.org/tip/3743d55b289c203d8f77b7cd47c24926b9d186ae
Author: Huang Rui <[email protected]>
AuthorDate: Sun, 25 Apr 2021 15:34:51 +08:00
Committer: Ingo Molnar <[email protected]>
CommitterDate: Thu, 13 May 2021 12:10:24 +02:00
x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations
Some AMD Ryzen generations has different calculation method on maximum
performance. 255 is not for all ASICs, some specific generations should use 166
as the maximum performance. Otherwise, it will report incorrect frequency value
like below:
~ → lscpu | grep MHz
CPU MHz: 3400.000
CPU max MHz: 7228.3198
CPU min MHz: 2200.0000
[ mingo: Tidied up whitespace use. ]
[ Alexander Monakov <[email protected]>: fix 225 -> 255 typo. ]
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")
Reported-by: Jason Bagavatsingham <[email protected]>
Fixed-by: Alexander Monakov <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Huang Rui <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Jason Bagavatsingham <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/include/asm/processor.h | 2 ++
arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++++
arch/x86/kernel/smpboot.c | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 6 +++++-
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 154321d..556b2b1 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -787,8 +787,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);
#ifdef CONFIG_CPU_SUP_AMD
extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_highest_perf(void);
#else
static inline u32 amd_get_nodes_per_socket(void) { return 0; }
+static inline u32 amd_get_highest_perf(void) { return 0; }
#endif
static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 2d11384..6d7b3b3 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1165,3 +1165,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
break;
}
}
+
+u32 amd_get_highest_perf(void)
+{
+ struct cpuinfo_x86 *c = &boot_cpu_data;
+
+ if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
+ (c->x86_model >= 0x70 && c->x86_model < 0x80)))
+ return 166;
+
+ if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
+ (c->x86_model >= 0x40 && c->x86_model < 0x70)))
+ return 166;
+
+ return 255;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 0ad5214..7770245 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -2043,7 +2043,7 @@ static bool amd_set_max_freq_ratio(void)
return false;
}
- highest_perf = perf_caps.highest_perf;
+ highest_perf = amd_get_highest_perf();
nominal_perf = perf_caps.nominal_perf;
if (!highest_perf || !nominal_perf) {
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index d1bbc16..7e74504 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -646,7 +646,11 @@ static u64 get_max_boost_ratio(unsigned int cpu)
return 0;
}
- highest_perf = perf_caps.highest_perf;
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ highest_perf = amd_get_highest_perf();
+ else
+ highest_perf = perf_caps.highest_perf;
+
nominal_perf = perf_caps.nominal_perf;
if (!highest_perf || !nominal_perf) {
On Thu, May 13, 2021 at 06:12:14PM +0800, Ingo Molnar wrote:
>
> * Huang Rui <[email protected]> wrote:
>
> > On Thu, May 13, 2021 at 06:59:02AM +0800, Ingo Molnar wrote:
> > >
> > > * Alexander Monakov <[email protected]> wrote:
> > >
> > > > On Sun, 25 Apr 2021, Huang Rui wrote:
> > > >
> > > > > Some AMD Ryzen generations has different calculation method on maximum
> > > > > perf. 255 is not for all asics, some specific generations should use 166
> > > > > as the maximum perf. Otherwise, it will report incorrect frequency value
> > > > > like below:
> > > >
> > > > The commit message says '255', but the code:
> > > >
> > > > > --- a/arch/x86/kernel/cpu/amd.c
> > > > > +++ b/arch/x86/kernel/cpu/amd.c
> > > > > @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> > > > > break;
> > > > > }
> > > > > }
> > > > > +
> > > > > +u32 amd_get_highest_perf(void)
> > > > > +{
> > > > > + struct cpuinfo_x86 *c = &boot_cpu_data;
> > > > > +
> > > > > + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> > > > > + (c->x86_model >= 0x70 && c->x86_model < 0x80)))
> > > > > + return 166;
> > > > > +
> > > > > + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> > > > > + (c->x86_model >= 0x40 && c->x86_model < 0x70)))
> > > > > + return 166;
> > > > > +
> > > > > + return 225;
> > > > > +}
> > > >
> > > > says 225? This is probably a typo? In any case they are out of sync.
> > > >
> > > > Alexander
> > >
> > > Ugh - that's indeed a good question ...
> > >
> >
> > Ah sorry! It's my typo. It should be 255 (confirmed in the ucode).
> >
> > Alexander, thanks a lot to catch this!
> >
> > Ingo, would you mind to update it from 225 -> 255 while you apply this
> > patch or let me know if you want me to send v5?
>
> No need to send v5, done!
>
> I have a system that appears to be affected by this bug:
>
> kepler:~> lscpu | grep -i mhz
> CPU MHz: 4000.000
> CPU max MHz: 7140.6250
> CPU min MHz: 2200.0000
>
> So I should be able to confirm after a reboot.
>
Thanks! Please feel free to let me know whether it's able to fix your
machine. :-)
Thanks,
Ray
* Ingo Molnar <[email protected]> wrote:
> No need to send v5, done!
>
> I have a system that appears to be affected by this bug:
>
> kepler:~> lscpu | grep -i mhz
> CPU MHz: 4000.000
> CPU max MHz: 7140.6250
> CPU min MHz: 2200.0000
>
> So I should be able to confirm after a reboot.
'CPU max Mhz' seems to be saner now:
kepler:~> lscpu | grep -i mhz
CPU MHz: 2200.000
CPU max MHz: 4917.9678
CPU min MHz: 2200.0000
Thanks,
Ingo