Bug 213115 - Unable to set the lowest frequency of AMD CPUs via cpupower - while kernel 5.12.4 (or 5.3.18) is booted with "nosmt"
Summary: Unable to set the lowest frequency of AMD CPUs via cpupower - while kernel 5....
Status: NEW
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: x86-64 Linux
: P1 low
Assignee: linux-pm@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-17 20:48 UTC by Yan Huang (Johnny)
Modified: 2023-11-24 06:47 UTC (History)
7 users (show)

See Also:
Kernel Version: 5.12.4
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
/proc/cpuinfo (5.46 KB, text/plain)
2021-05-17 20:59 UTC, Yan Huang (Johnny)
Details
cpupower frequency-info (817 bytes, text/plain)
2021-05-17 21:01 UTC, Yan Huang (Johnny)
Details

Description Yan Huang (Johnny) 2021-05-17 20:48:32 UTC
(Opening this bug as a junior team member of the SUSE Customer Support)

A SUSE customer wasn't able to set the lowest possible CPU frequency value via cpupower on SUSE Linux Enterprise Desktop 15 SP2 (with the kernel 5.3.18) on machines with AMD A12-9720P and AMD Ryzen 5 3550H - while they were booted with "nosmt".

The customer said that this was working on the previous SUSE Linux Enterprise Desktop 15 SP1 (with the kernel 4.12.14).

Just for this purpose, I purchased a laptop Lenovo IdeaPad 3-15ADA05 with AMD Ryzen 3 3250U and was able to replicate the issue - with the kernel 5.3.18 (the default one for SUSE Linux Enterprise Desktop 15 SP2) and the newest stable kernel 5.12.4.

AMD Ryzen 3 3250U
- https://www.amd.com/en/products/apu/amd-ryzen-3-3250u
- 1st gen Zen
- 2 cores, 4 threads
- base frequency: 2.60 GHz
- boost frequency: 3.50 GHz
- cpupower frequency-info
 -- hardware limits: 1.40 GHz - 2.60 GHz
 -- available frequency steps: 2.60 GHz, 1.70 GHz, 1.40 GHz

Each time, I ran this command and expected the CPU core/thread frequencies to be =< 1400 MHz:
modprobe cpufreq_userspace && cpupower frequency-set -g userspace && cpupower frequency-set -f 1.40GHz && echo 0 > /sys/devices/system/cpu/cpufreq/boost


Default kernel 5.3.18

I. without "nosmt" (ok)
1) initially:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1308.436
> cpu MHz               : 1218.734
> cpu MHz               : 1301.057
> cpu MHz               : 1377.824
2) after running the command:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1394.225
> cpu MHz               : 1391.125
> cpu MHz               : 1352.398
> cpu MHz               : 1356.574

II. with "nosmt" (fail)
1) initially:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1434.860
> cpu MHz               : 1557.750
2) after running the command:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 2068.443
> cpu MHz               : 1921.816


Kernel 4.12.14 - obtained from https://download.opensuse.org/repositories/Kernel:/SLE15-SP1/standard/x86_64/ (no longer available)

I. without "nosmt" (ok)
1) initially:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1700.000
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000
2) after running the command:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000

II. with "nosmt" (ok)
1) initially:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000
2) after running the command:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000


Kernel 5.12.4 - obtained from https://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/

I. without "nosmt" (ok)
1) initially:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000
> cpu MHz               : 2263.054
> cpu MHz               : 1269.757
2) after running the command:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1400.000
> cpu MHz               : 1340.634
> cpu MHz               : 1400.000
> cpu MHz               : 1400.000

II. with "nosmt" (fail)
1) initially:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1494.915
> cpu MHz               : 2600.000
2) after running the command:
> localhost:~ # grep MHz /proc/cpuinfo
> cpu MHz               : 1731.255
> cpu MHz               : 1400.000


I also tested various kernel versions from http://download.opensuse.org/repositories/home:/tiwai:/kernel:/ - it seems that the issue started in 5.1.x or earlier (I wasn't able to boot every kernel version).

I opened a SUSE Bugzilla bug bsc#1175231, but it was decided to not pursue a fix for this corner-case issue at SUSE's level (the solution is to just avoid "nosmt").

The issue should be replicable even on openSUSE Leap 15.2 with the above mentioned kernels.

It is possible that the issue is limited to the 1st generation of AMD Ryzen CPUs (and AMD's pre-Ryzen CPUs).
Comment 1 Yan Huang (Johnny) 2021-05-17 20:59:46 UTC
Created attachment 296817 [details]
/proc/cpuinfo

Attaching /proc/cpuinfo from my own laptop Lenovo IdeaPad 3-15ADA05 with AMD Ryzen 3 3250U (while "nosmt" wasn't set)
Comment 2 Yan Huang (Johnny) 2021-05-17 21:01:41 UTC
Created attachment 296821 [details]
cpupower frequency-info

Attaching the "cpupower frequency-info" output from my own laptop Lenovo IdeaPad 3-15ADA05 with AMD Ryzen 3 3250U (while "nosmt" wasn't set and before running the command mentioned in the comment #0)
Comment 3 Perry Yuan(AMD) 2023-11-23 08:30:09 UTC
Hi Johnny

looks like you are using acpi_cpufreq driver instead of amd_pstate or amd_pstate_epp.

localhost:~ # cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq

Could you provide the output of "lscpu -ae" ?
It will show the frequency for min/max

Perry.
Comment 4 xiaojian.du 2023-11-24 06:47:53 UTC
I think it is expected that 2 threads will get higher average loading than 4 threads, then it makes the cpu freq stay at one higher level.

Note You need to log in before you can comment on or make changes to this bug.