Created attachment 305131 [details] Power Options: Processor Power Management in Windows It would be really great if amd-pstate had a feature parity with acpi-cpufreq, namely 1) Being able to set operating frequencies (maximum, minimum and user-defined) 2) Being able to enable/disable boost Currently both features are not available and frequency control is simply ignored (bug 215800). Rationale: 1) This is required for benchmarking and proper temperature control. Boost frequencies are subject to multiple limitations (power in watts, amperage, voltage, temperature, BIOS limitations) and can change depending on the workload. Setting a low enough frequency allows to run benchmarks in the controlled environment and get proper data. Windows allows to do that easily, see the attached screenshot. 2) Disabling boost is an easy option to subdue operating temperatures though if the previous issue is tackled, it's not really needed.
*** Bug 215800 has been marked as a duplicate of this bug. ***
Created attachment 305133 [details] signature.asc On Wed, Sep 20, 2023 at 11:06:51AM +0000, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217931 > > Bug ID: 217931 > Summary: amd-pstate lacks crucial features: CPU frequency and > boost control > Product: Power Management > Version: 2.5 > Hardware: AMD > OS: Linux > Status: NEW > Severity: high > Priority: P3 > Component: cpufreq > Assignee: linux-pm@vger.kernel.org > Reporter: aros@gmx.com > Regression: No > > Created attachment 305131 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=305131&action=edit > Power Options: Processor Power Management in Windows > > It would be really great if amd-pstate had a feature parity with > acpi-cpufreq, > namely > > 1) Being able to set operating frequencies (maximum, minimum and > user-defined) ondemand, conservative, performance? > > 2) Being able to enable/disable boost What is boost? > > Currently both features are not available and frequency control is simply > ignored (bug 215800). > > Rationale: > > 1) This is required for benchmarking and proper temperature control. Boost > frequencies are subject to multiple limitations (power in watts, amperage, > voltage, temperature, BIOS limitations) and can change depending on the > workload. Setting a low enough frequency allows to run benchmarks in the > controlled environment and get proper data. > > Windows allows to do that easily, see the attached screenshot. > > 2) Disabling boost is an easy option to subdue operating temperatures though > if > the previous issue is tackled, it's not really needed. For example, after compiling the kernel one needs to cool down system, right?
> ondemand, conservative, performance? (Intel|AMD) CPU pstate drivers work differently and those are ignored: https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html https://wiki.archlinux.org/title/CPU_frequency_scaling
(In reply to Artem S. Tashkinov from comment #0) > Created attachment 305131 [details] > Power Options: Processor Power Management in Windows > > It would be really great if amd-pstate had a feature parity with > acpi-cpufreq, namely > > 1) Being able to set operating frequencies (maximum, minimum and > user-defined) > > 2) Being able to enable/disable boost > > Currently both features are not available and frequency control is simply > ignored (bug 215800). > > Rationale: > > 1) This is required for benchmarking and proper temperature control. Boost > frequencies are subject to multiple limitations (power in watts, amperage, > voltage, temperature, BIOS limitations) and can change depending on the > workload. Setting a low enough frequency allows to run benchmarks in the > controlled environment and get proper data. > > Windows allows to do that easily, see the attached screenshot. > > 2) Disabling boost is an easy option to subdue operating temperatures though > if the previous issue is tackled, it's not really needed. Thanks for the suggestion. There are two modes for amd pstate driver, one passive, and another active mode, the passive mode already has the boost control feature. # cat /sys/devices/system/cpu/cpufreq/boost 1 I have raised this requestion and will get active mode supported with a new patch. Perry.
(In reply to Perry Yuan(AMD) from comment #4) > (In reply to Artem S. Tashkinov from comment #0) > > Created attachment 305131 [details] > > Power Options: Processor Power Management in Windows > > > > It would be really great if amd-pstate had a feature parity with > > acpi-cpufreq, namely > > > > 1) Being able to set operating frequencies (maximum, minimum and > > user-defined) > > > > 2) Being able to enable/disable boost > > > > Currently both features are not available and frequency control is simply > > ignored (bug 215800). > > > > Rationale: > > > > 1) This is required for benchmarking and proper temperature control. Boost > > frequencies are subject to multiple limitations (power in watts, amperage, > > voltage, temperature, BIOS limitations) and can change depending on the > > workload. Setting a low enough frequency allows to run benchmarks in the > > controlled environment and get proper data. > > > > Windows allows to do that easily, see the attached screenshot. > > > > 2) Disabling boost is an easy option to subdue operating temperatures > though > > if the previous issue is tackled, it's not really needed. > > Thanks for the suggestion. > There are two modes for amd pstate driver, one passive, and another active > mode, the passive mode already has the boost control feature. > > # cat /sys/devices/system/cpu/cpufreq/boost > 1 > > I have raised this requestion and will get active mode supported with a new > patch. > Thank you for chiming in, Perry! I'm looking forward to being able to control min/max frequency which kinda negates the need for boost control. I know this can be done since the Windows CPPC driver allows that perfectly.
This would also be hugely useful for hundreds of thousands of AMD handheld users (not limited to Steam Deck).
I'm also looking for a way to contol min/max frequency. I tried active, passive and guided modes and was surprised none obeyed scaling_max_freq.
(In reply to hej from comment #7) > I'm also looking for a way to contol min/max frequency. I tried active, > passive and guided modes and was surprised none obeyed scaling_max_freq. It's currently not implemented at all in amd-pstate, so those knobs (scaling_max_freq|scaling_min_freq|scaling_setspeed) do nothing.
Mario, it would be great if AMD devoted some resources to adding these features.
Hi Artem I have implemented the boost control for amd-pstate passive and active mode driver, the patches are under reviewing, will sent out for testing once we finish internal review procvess. Perry
Hi Perry, is it possible to also add scaling_max_freq support to amd-pstate? I'd like to restrict max frequency on the cpu. Thanks.
Got to test the new changes in 6.7 , and it does work, but max frequency changes didn't really seem to apply well. Initially I figured that changes were just not deterministic, but later I successfully figured that the first change (after boot?) just doesn't take effect, and then setting the same value also doesn't make any change, so setting a higher then desired value, then setting the desired value does the trick. According to htop reported values, the frequency still exceeds the maximum, but based on both power consumption and performance, the max frequency setting does something after all, I'm just not really sure how reliable it is, but it's neat to have something. Almost forgot to report here as planned, but coincidentally I needed to use CUDA, and totally fortunately Nvidia doesn't feel like supporting the latest kernel yet, so I'm back on 6.5 and I get to enjoy the heat again with long running test which reminded me of this bug report. So generally recommending updating to 6.7 if this feature is really desired. I'm surely missing it, the stupid high frequency by default is okay for bursty tasks, but it's definitely great to be able to restrict it on demand.
Created attachment 305668 [details] attachment-3602-0.html Hello, Thank you for reaching out. I am currently in OOO until 12/29 response will be delayed. Best regards, Perry Yuan
Got back to a more recent kernel and found out that apparently the issue is sillier than expected. It's not the first change that's failing, but when setting a new frequency limit, the previous limit gets applied instead. So for example after a fresh boot: - Set 4.0 GHz -> Nothing changes - Set 4.5 GHz -> 4.0 GHz limit gets applied - Set 4.3 GHz -> 4.5 GHz limit gets applied - Set 4.3 GHz -> Nothing changes because it's already supposed to be 4.3 GHz - Set 4.2 GHz -> 4.3 GHz limit gets applied Way better than nothing, but it's surely odd this way. Good to know its quirk though, earlier I just thought it was simply not really reliable, but explicitly working around its silly issue makes it useful.
Can confirm the same behavior Pedro experienced with 6.7.0. Definitely is odd. One way I've reliably found to set a max frequency is to first set the frequency you desire, and then set the max frequency to a value that is either lower than the minimum, or higher than the maximum, supported frequencies. Seemingly related, but as of 6.7.0, the system sometimes gets stuck at its lowest supported frequency, requiring a manual increase to the maximum frequency that involves the process I described above. It's the issue that led down this rabbit hole originally.
When you say getting stuck in lowest supported frequency does it resemble bug 218305 perhaps? What is your CPU scaling governor when it happened? And does it only happen with suspend/resume or only with reboot?
> When you say getting stuck in lowest supported frequency does it resemble bug > 218305 perhaps? It's the same bug I've just refiled it. > What is your CPU scaling governor when it happened? And does it only happen > with suspend/resume or only with reboot? cpupower frequency-info analyzing CPU 4: driver: amd-pstate-epp CPUs which run at the same hardware frequency: 4 CPUs which need to have their frequency coordinated by software: 4 maximum transition latency: Cannot determine or is not supported. hardware limits: 400 MHz - 5.61 GHz available cpufreq governors: performance powersave current policy: frequency should be within 400 MHz and 5.61 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 1.40 GHz (asserted by call to kernel) boost state support: Supported: yes Active: yes AMD PSTATE Highest Performance: 214. Maximum Frequency: 5.61 GHz. AMD PSTATE Nominal Performance: 145. Nominal Frequency: 3.80 GHz. AMD PSTATE Lowest Non-linear Performance: 42. Lowest Non-linear Frequency: 1.10 GHz. AMD PSTATE Lowest Performance: 16. Lowest Frequency: 400 MHz. It happens both with amd-pstate-epp and acpi-cpufreq. It only happens after a random number of suspend/resume cycles (as low as one, as high as three or four). Rebooting/power cycling always fixes the issue.
I was meaning #14/#15. I want to see if they're finding the same thing as you. Looking for a pattern.
(In reply to Mario Limonciello (AMD) from comment #18) > I was meaning #14/#15. I want to see if they're finding the same thing as > you. Looking for a pattern. The amd-pstate driver doesn't allow to set any frequency limits, so I'm not sure how people here have achieved this. And I'm not using acpi-cpufreq any longer. I like amd-pstate more since it shows CPU cores frequency better/more precisely.
Haven't seen any other issue than the one I described earlier, but then I also haven't experimented a whole lot, just wanted to figure out what gets me a reliable frequency cap I can adjust at will, and I have that in the scripted form of: - Set [target] freq - Safety sleep - Set [target + 1] freq That never failed to set [target] frequency so far. The sleep part should be optional, but then the whole script shouldn't be required as a starter, so I just chose to fight bugs with hacks. > The amd-pstate driver doesn't allow to set any frequency limits, so I'm not > sure how people here have achieved this. Are you using a recent enough kernel as discussed earlier? It's quite unlikely to have that by just using a distribution provided stock kernel. Once the kernel version is recent enough, it's as easy as running something like the following as root: `echo 3000000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq` Just keep in mind the mentioned issue of the current limit always being what was requested previously.
I did echo 3000000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq 3000000 on Linux 6.6.x and it did exactly nothing. cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 3000000 Cores continue to hit their respective max frequencies all the time. Fedora hasn't yet published Linux 6.7.
I repeated Artem's test on 6.7.0-rc6 (Void Linux with custom kernel---a bit old, sorry). My energy performance preference is set to "power". I think I am seeing roughly what Pedro describes. Writing twice to scaling_max_freq is definitely doing something, at least if we believe the numbers reported by htop or cpupower. Usually I cannot keep all of my cores (7840U) at 400 MHz; the active ones are habitually between 1-3 GHz. After following the above recipe, the active cores seem limited to ~544 MHz instead. (Although, since the amd-pstate-epp driver reputedly does not allow setting limits at all, I suppose we should consider the possibility that these reported numbers are incorrect ;) It would sure be nice to have the non-determinism (i.e. bugs) ironed out of the driver first, then consider supporting scaling_max_frequency. I am actually open to the idea---in principle---that the EPP stuff obsoletes max_frequency, but I have to say, the entire scale is still biased too far towards performance. There ought to be a way for the user to basically tell the system "POWER POWER POWER above all, and I really mean it!!" but as it stands, the furthest that we are allowed to push things is still fairly weak: any core with the slightest activity is immediately boosted way up, so even an "idle" system constantly has a few cores way above idle speed. This might be why folks are asking for a frequency cap. Why isn't EPP more of a logarithmic scale, where both ends of the scale are so ridiculously overkill that most people will want a setting closer to the middle? *That* is how it should be designed.
6.7-rc4 was /supposed/ to fix the kind of bug that Pedro described. See this commit. https://github.com/torvalds/linux/commit/febab20caebac959fdc3d7520bc52de8b1184455 There must be another problem though; I wonder if something isn't getting flushed out still.
I'll try to update to 6.7.0 or 6.7.1 this weekend and see how/if the behavior changes on my system. Do I read that commit correctly, that scaling_max_frequency *is* supposed to cap the CPU frequencies, in the latest kernels?
Writing scaling_max_freq updates the cpufreq policy (see store_##file_name). That function through a series of events (see freq_qos_update_request()) is supposed to be calling into amd-pstate to flush it out to hardware. For passive/guided mode it uses .target() callback for amd-pstate. For active mode it uses ,setpolicy() callback for amd-pstate-epp. Can you guys try turning on the dynamic debugging for amd-pstate? It has a debug line that will confirm when policies are flushed from the core into the driver. pr_debug("set_policy: cpuinfo.max %u policy->max %u\n", policy->cpuinfo.max_freq, policy->max); That can help give a hint if this is a core or driver issue that it's not working immediately.
I tried on a Phoenix system myself, and I can reproduce what I think is the same issue here. I did experiment with writing MSR_AMD_CPPC_ENABLE after writing MSR_AMD_CPPC_REQ to force the request but it didn't work. I'll talk to some people offline about it.
(In reply to Mario Limonciello (AMD) from comment #16) > When you say getting stuck in lowest supported frequency does it resemble > bug 218305 perhaps? Looking at bug 218305, I haven't noticed if the issue is triggered by suspend/resume or restart cycles. I'm on a laptop that regularly goes through several days of use before being rebooted, so it's possible. I'll keep an eye out to see if that's related. From what I experienced, the issue would occur while using the machine for a few hours, and the issue would "fix" itself upon a suspend/resume or restart. As far as similarities to bug 218305, I'm also running a Ryzen APU (on Zen 3 and not 4) on an HP Dev One, which I believe is a modified Elitebook 845 G8 or G9. However, I've been told by HP support and the System76 team they outsourced the project to that the firmware on the Dev One was custom written for the project and unrelated to the standard Elitebook line's firmware. I also use `ryzenadj` to set STAPM, PPT FAST and SLOW limits. Like in bug 218305, I also leave my laptop plugged in the majority of the time. When I experience the issue again, I'll look at more diagnostics to see if it's like bug 218305. > What is your CPU scaling governor when it happened? I use the amd-pstate-epp driver in active mode, and alternate between the powersave and performance governors depending on whether I'm on battery power or not, and delegate that switch to power-profiles-daemon versus using sysfs. It's happened while on AC power, so it is likely I was using the performance governor when I experienced the issue.
Created attachment 305727 [details] sysfs, ryzenadj and cpupower output
It happened again ~90min after doing a `systemctl kexec` and using `ryzenadj`, so I can better answer your questions. (In reply to Mario Limonciello (AMD) from comment #16) > When you say getting stuck in lowest supported frequency does it resemble > bug 218305 perhaps? It seems to differ from bug 218305 in that the values `ryzenadj -i` returns seem sane on my machine, whereas in the other bug report they weren't. I'm also getting the correct reporting for the maximum supported frequency for all of my cores. I can't say what triggers it, but I've noticed it most when using the machine for a couple of hours, sometimes while using the processor moderately but not excessively. > What is your CPU scaling governor when it happened? And does it only happen > with suspend/resume or only with reboot? This time it happened with the performance governor. I added an attachment with the output of ryzenadj, cpupower and sysfs taken while the machine was stuck at 400MHz
(In reply to Mario Limonciello (AMD) from comment #23) > 6.7-rc4 was /supposed/ to fix the kind of bug that Pedro described. See > this commit. > https://github.com/torvalds/linux/commit/ > febab20caebac959fdc3d7520bc52de8b1184455 > > There must be another problem though; I wonder if something isn't getting > flushed out still. Figured that was for getting the functionality working at all. There are only 3 relevant commits in 2 days, and one from that is only a visual change. Before those the functionality simply just didn't work at all, and after those apparently the silly behavior described is easy to reproduce. (In reply to AlexDeLorenzo.dev from comment #29) > It happened again ~90min after doing a `systemctl kexec` and using > `ryzenadj`, so I can better answer your questions. Apparently ryzenadj directly communicates with the SMU without using an in-tree kernel module to use an interface blessed by AMD, so that's highly unlikely to get support from them. Recommending reproducing the issue without using that at all first, it's going to keep on getting the blame until it's proven not to interfere. Do you happen to know such tools for Raphael (7000 series, Zen 4 based desktop)? Investigating silly memory and/or IMC issues, was happy to see ryzen_smu reporting a whole lot of relevant info, but then it turned out to be abandoned, and forks claiming to support Raphael don't seem to target my root complex (PCI_DEVICE_ID_AMD_19H_M60H_ROOT). Worst case I'll make a Windows setup and check the tools there, just hoped to be able to avoid that. I hate BIOS "Auto" settings with a passion not even showing current values, and the CPU's memory controller seems to be quite finicky.
Not sure if related, but apparently a bug was introduced back in November which could cause the CPU to be stuck at the lowest frequency, and it was fixed recently: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0d326da462e20285236e11e4cbc32085de9f363
> Apparently ryzenadj directly communicates with the SMU without using an > in-tree kernel module to use an interface blessed by AMD, so that's highly > unlikely to get support from them. > Recommending reproducing the issue without using that at all first, it's > going to keep on getting the blame until it's proven not to interfere. Yes please do it without *anything* abusing that mailbox at all during the boot (like ryzenadj or ryzen_smu). It's entirely possible that another piece of firmware fights over the same interfaces or data structures and that's part of a problem. It's also possible that attempts to read information using that tool unintentionally causes information to also be written (as it's a reverse engineered tool that uses an undocumented engineering interface anything is possible) The simpler the reproduce the better. As I mentioned in the other issue, to rule out a kernel bug we may want to look at the output of these MSRs while the issue happened. If those are correct for what has been programmed to scaling_max_freq, then we may be dealing with a firmware bug. #define MSR_AMD_CPPC_CAP1 0xc00102b0 #define MSR_AMD_CPPC_ENABLE 0xc00102b1 #define MSR_AMD_CPPC_CAP2 0xc00102b2 #define MSR_AMD_CPPC_REQ 0xc00102b3 #define MSR_AMD_CPPC_STATUS 0xc00102b4
Can you guys please test this: https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.limonciello@amd.com/T/#u
Bah, tried to test #33 first based on emails, but found out the hard way that deb packaged kernel installation stopped properly replacing the previous kernel at some point so I was testing nothing, and the comment is gone anyway. (In reply to Mario Limonciello (AMD) from comment #34) > Can you guys please test this: > > https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario. > limonciello@amd.com/T/#u This one seems to be a winner, the frequency limit seems to be updated correctly after applying the changes (by hand).
(In reply to Pedro from comment #30) > Recommending reproducing the issue without using that at all first, it's > going to keep on getting the blame until it's proven not to interfere. So I shutdown the PC and started it, disabled any scripts that might trigger `ryzenadj` beforehand. There were no suspend/resume cycles since booting. About 4 hours later, the CPU was stuck at 400MHz. (In reply to Mario Limonciello (AMD) from comment #32) > As I mentioned in the other issue, to rule out a kernel bug we may want to > look at the output of these MSRs while the issue happened. If those are > correct for what has been programmed to scaling_max_freq, then we may be > dealing with a firmware bug. > > #define MSR_AMD_CPPC_CAP1 0xc00102b0 > #define MSR_AMD_CPPC_ENABLE 0xc00102b1 > #define MSR_AMD_CPPC_CAP2 0xc00102b2 > #define MSR_AMD_CPPC_REQ 0xc00102b3 > #define MSR_AMD_CPPC_STATUS 0xc00102b4 MSRs before: 0xc00102b0: ba46290fba46290f 0xc00102b1: 1 0xc00102b2: 0 0xc00102b3: a6a6 0xc00102b4: 0 MSRs while forced underclock: 0xc00102b0: ba46290fba46290f 0xc00102b1: 1 0xc00102b2: 0 0xc00102b3: e0e 0xc00102b4: 0 (In reply to Mario Limonciello (AMD) from comment #34) > Can you guys please test this: > > https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario. > limonciello@amd.com/T/#u I'll give this a go.
(In reply to Mario Limonciello (AMD) from comment #34) > Can you guys please test this: > > https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario. > limonciello@amd.com/T/#u I applied the amd-pstate patch to 6.7.0, and have been running it for the day without problems. There were several suspend/resume cycles in that time. Haven't used ryzenadj or rebooted. Before the patch, I would experience the issue within a few hours. After waiting ~20 hours, I tried using cpupower to set the maximum frequency and was successful. Didn't have to do it twice. The patch seems to be the fix.
It's been ~2 days and haven't run into this issue once while using the patch. I've also used ryzenadj without issue during that time. Pretty sure it's the fix to this issue entirely.
Hi all, The new boost control patches are under reviewing now. https://lore.kernel.org/lkml/cover.1706255676.git.perry.yuan@amd.com/ It will be great if anyone would like help to test this on your system if you are interested in this feature. Perry.
Could this be the reason why some CPU's do not boost to their maximum frequency, while they are happy to do so on Windows? For example my 5800X3D never reaches 4550 on Linux, but on Windows it seems to have no problem getting there.
(In reply to Sjoer van der Ploeg from comment #40) > Could this be the reason why some CPU's do not boost to their maximum > frequency, while they are happy to do so on Windows? > > For example my 5800X3D never reaches 4550 on Linux, but on Windows it seems > to have no problem getting there. Could you share the output with below commands? then I can check that. echo "=============norminal freq===============================" cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_freq echo "=============norminal perf===============================" cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_perf echo "=============highest_perf perf===============================" cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf echo "=============lowest_nonlinear_perf perf===============================" cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_nonlinear_perf echo "=============lowest perf===============================" cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_perf echo "=============lowest freq===============================" cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_freq Perry.
So, how does setting the maximum frequency work? Running 6.7.3 here, Ryzen 7 5800X. $ grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_highest_perf:166 /sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_lowest_nonlinear_freq:1752000 /sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_max_freq:4929000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:4929000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:550000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:0 /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences:default performance balance_performance balance_power power /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference:performance /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:performance powersave /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:550000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:amd-pstate-epp /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:4000000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:550000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> The CPU happily runs at its maximum frequency despite scaling_max_freq=4000000. # echo 4000000 > amd_pstate_max_freq bash: amd_pstate_max_freq: Permission denied
Lastly, this looks wrong: # cat /sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_max_freq 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 4929000 This CPU cores boost to _different_ frequencies.
cpufreq_freq_attr_ro(amd_pstate_max_freq); the sysfs entry is ready only, so it is not allowing to write the new max freq value to it. you can try to limit the freq with scaling_max_freq and scaling_min_freq. The boost patches and scaling_max_freq support are not same topics, if the boost patches can work, however scaling_max_freq is not working, we can file a new ticket to track that problem. Perry.
/sys/devices/system/cpu/cpu0/cpufreq$ ll total 0 drwxr-xr-x 2 root root 0 Jan 11 00:41 ./ drwxr-xr-x 26 root root 0 Jan 11 00:41 ../ -r--r--r-- 1 root root 4096 Feb 1 03:54 affected_cpus -r--r--r-- 1 root root 4096 Feb 1 03:54 amd_pstate_highest_perf -r--r--r-- 1 root root 4096 Feb 1 03:54 amd_pstate_lowest_nonlinear_freq -r--r--r-- 1 root root 4096 Feb 1 03:54 amd_pstate_max_freq -r--r--r-- 1 root root 4096 Jan 11 00:41 cpuinfo_max_freq -r--r--r-- 1 root root 4096 Jan 11 00:41 cpuinfo_min_freq -r--r--r-- 1 root root 4096 Feb 1 03:54 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Feb 1 03:54 energy_performance_available_preferences -rw-r--r-- 1 root root 4096 Feb 1 03:54 energy_performance_preference -r--r--r-- 1 root root 4096 Feb 1 03:54 related_cpus -r--r--r-- 1 root root 4096 Feb 1 03:54 scaling_available_governors -r--r--r-- 1 root root 4096 Feb 1 03:54 scaling_cur_freq -r--r--r-- 1 root root 4096 Jan 15 01:16 scaling_driver -rw-r--r-- 1 root root 4096 Feb 1 03:54 scaling_governor -rw-r--r-- 1 root root 4096 Feb 1 03:54 scaling_max_freq -rw-r--r-- 1 root root 4096 Feb 1 03:54 scaling_min_freq -rw-r--r-- 1 root root 4096 Feb 1 03:54 scaling_setspeed You can see, only the last three entries are allowed to write new values.
(In reply to Perry Yuan(AMD) from comment #44) > cpufreq_freq_attr_ro(amd_pstate_max_freq); > > the sysfs entry is ready only, so it is not allowing to write the new max > freq value to it. > > you can try to limit the freq with scaling_max_freq and scaling_min_freq. Exactly what I did, I set scaling_max_freq for all cores to 4GHz (4000000) - it had zero effect. > > The boost patches and scaling_max_freq support are not same topics, if the > boost patches can work, however scaling_max_freq is not working, we can file > a new ticket to track that problem. >
Created attachment 305807 [details] attachment-17058-0.html [AMD Official Use Only - General] thanks for confirming this, we will take a look the issue and get a fix for the max,min scaling set function. Perry. 获取 Outlook for iOS<https://aka.ms/o0ukef> ________________________________ 发件人: bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org> 发送时间: Thursday, February 1, 2024 5:58:58 PM 收件人: Yuan, Perry <Perry.Yuan@amd.com> 主题: [Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control https://bugzilla.kernel.org/show_bug.cgi?id=217931 --- Comment #46 from Artem S. Tashkinov (aros@gmx.com) --- (In reply to Perry Yuan(AMD) from comment #44) > cpufreq_freq_attr_ro(amd_pstate_max_freq); > > the sysfs entry is ready only, so it is not allowing to write the new max > freq value to it. > > you can try to limit the freq with scaling_max_freq and scaling_min_freq. Exactly what I did, I set scaling_max_freq for all cores to 4GHz (4000000) - it had zero effect. > > The boost patches and scaling_max_freq support are not same topics, if the > boost patches can work, however scaling_max_freq is not working, we can file > a new ticket to track that problem. > -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug.
Did you pick up https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario.limonciello@amd.com/T/#u ?
(In reply to Mario Limonciello (AMD) from comment #48) > Did you pick up > https://lore.kernel.org/linux-pm/20240119113319.54158-1-mario. > limonciello@amd.com/T/#u ? I'm running 6.7.3 which ostensibly includes it: commit c794cc65bb3eef3142bbecd48f1fd43f1fa8d478 Author: Mario Limonciello Date: Fri Jan 19 05:33:19 2024 -0600 cpufreq/amd-pstate: Fix setting scaling max/min freq values
And just in case: $ cat /sys/devices/system/cpu/amd_pstate/status active
(In reply to Artem S. Tashkinov from comment #50) > And just in case: > > $ cat /sys/devices/system/cpu/amd_pstate/status > active Got it, thanks for the info. We will get the scaling_max/min fixed with other patches. This ticket is focusing on the boost control feature. Perry.
(In reply to Perry Yuan(AMD) from comment #41) > (In reply to Sjoer van der Ploeg from comment #40) > > Could this be the reason why some CPU's do not boost to their maximum > > frequency, while they are happy to do so on Windows? > > > > For example my 5800X3D never reaches 4550 on Linux, but on Windows it seems > > to have no problem getting there. > > Could you share the output with below commands? then I can check that. > > echo "=============norminal freq===============================" > cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_freq > > echo "=============norminal perf===============================" > cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_perf > > echo "=============highest_perf perf===============================" > cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf > > echo "=============lowest_nonlinear_perf perf===============================" > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_nonlinear_perf > > echo "=============lowest perf===============================" > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_perf > > echo "=============lowest freq===============================" > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_freq > > Perry. =============nominal freq=============================== 3401 =============nominal perf=============================== 124 =============highest_perf perf=============================== 196 171 196 166 186 181 191 176 171 196 166 186 181 191 196 176 =============lowest_nonlinear_perf perf=============================== 64 =============lowest perf=============================== 21 =============lowest freq=============================== 550 Only removed repeating values
(In reply to Sjoer van der Ploeg from comment #52) > (In reply to Perry Yuan(AMD) from comment #41) > > (In reply to Sjoer van der Ploeg from comment #40) > > > Could this be the reason why some CPU's do not boost to their maximum > > > frequency, while they are happy to do so on Windows? > > > > > > For example my 5800X3D never reaches 4550 on Linux, but on Windows it > seems > > > to have no problem getting there. > > > > Could you share the output with below commands? then I can check that. > > > > echo "=============norminal freq===============================" > > cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_freq > > > > echo "=============norminal perf===============================" > > cat /sys/devices/system/cpu/cpu*/acpi_cppc/nominal_perf > > > > echo "=============highest_perf perf===============================" > > cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf > > > > echo "=============lowest_nonlinear_perf > perf===============================" > > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_nonlinear_perf > > > > echo "=============lowest perf===============================" > > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_perf > > > > echo "=============lowest freq===============================" > > cat /sys/devices/system/cpu/cpu*/acpi_cppc/lowest_freq > > > > Perry. > > =============nominal freq=============================== > 3401 > =============nominal perf=============================== > 124 > =============highest_perf perf=============================== > 196 > 171 > 196 > 166 > 186 > 181 > 191 > 176 > 171 > 196 > 166 > 186 > 181 > 191 > 196 > 176 > =============lowest_nonlinear_perf perf=============================== > 64 > =============lowest perf=============================== > 21 > =============lowest freq=============================== > 550 > > Only removed repeating values How about the output of "lscpu -ae"?
(In reply to Perry Yuan(AMD) from comment #53) > How about the output of "lscpu -ae"? Sorry for the late reply: CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ 0 0 0 0 0:0:0:0 yes 4550.0000 550.0000 3569.5090 1 0 0 1 1:1:1:0 yes 4550.0000 550.0000 3552.6860 2 0 0 2 2:2:2:0 yes 4550.0000 550.0000 3559.3779 3 0 0 3 3:3:3:0 yes 4550.0000 550.0000 3854.7759 4 0 0 4 4:4:4:0 yes 4550.0000 550.0000 3590.6599 5 0 0 5 5:5:5:0 yes 4550.0000 550.0000 3552.8989 6 0 0 6 6:6:6:0 yes 4550.0000 550.0000 3840.7690 7 0 0 7 7:7:7:0 yes 4550.0000 550.0000 3584.2910 8 0 0 0 0:0:0:0 yes 4550.0000 550.0000 3546.3811 9 0 0 1 1:1:1:0 yes 4550.0000 550.0000 3551.5229 10 0 0 2 2:2:2:0 yes 4550.0000 550.0000 3591.2500 11 0 0 3 3:3:3:0 yes 4550.0000 550.0000 3594.0801 12 0 0 4 4:4:4:0 yes 4550.0000 550.0000 3552.0400 13 0 0 5 5:5:5:0 yes 4550.0000 550.0000 3572.1050 14 0 0 6 6:6:6:0 yes 4550.0000 550.0000 4124.7349 15 0 0 7 7:7:7:0 yes 4550.0000 550.0000 3583.7170
(In reply to Sjoer van der Ploeg from comment #54) > (In reply to Perry Yuan(AMD) from comment #53) > > How about the output of "lscpu -ae"? > > Sorry for the late reply: > > CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ > 0 0 0 0 0:0:0:0 yes 4550.0000 550.0000 3569.5090 > 1 0 0 1 1:1:1:0 yes 4550.0000 550.0000 3552.6860 > 2 0 0 2 2:2:2:0 yes 4550.0000 550.0000 3559.3779 > 3 0 0 3 3:3:3:0 yes 4550.0000 550.0000 3854.7759 > 4 0 0 4 4:4:4:0 yes 4550.0000 550.0000 3590.6599 > 5 0 0 5 5:5:5:0 yes 4550.0000 550.0000 3552.8989 > 6 0 0 6 6:6:6:0 yes 4550.0000 550.0000 3840.7690 > 7 0 0 7 7:7:7:0 yes 4550.0000 550.0000 3584.2910 > 8 0 0 0 0:0:0:0 yes 4550.0000 550.0000 3546.3811 > 9 0 0 1 1:1:1:0 yes 4550.0000 550.0000 3551.5229 > 10 0 0 2 2:2:2:0 yes 4550.0000 550.0000 3591.2500 > 11 0 0 3 3:3:3:0 yes 4550.0000 550.0000 3594.0801 > 12 0 0 4 4:4:4:0 yes 4550.0000 550.0000 3552.0400 > 13 0 0 5 5:5:5:0 yes 4550.0000 550.0000 3572.1050 > 14 0 0 6 6:6:6:0 yes 4550.0000 550.0000 4124.7349 > 15 0 0 7 7:7:7:0 yes 4550.0000 550.0000 3583.7170 The max frequency value is correct to be 4.55GHZ on your system by the CPPC capabilities reported by your firmware. 4.55GHZ is boost frequency which cannot maintain long time, it can try EPP mode & performance profile, and run some lighter workload, the freq will be reaching to max freq. > 14 0 0 6 6:6:6:0 yes 4550.0000 550.0000 4124.7349 seeing from this, the freq is close to 4.5GHz, please try the EPP and performance profile on your system. then check the lscpu -ae output to confirm if it can reach 4.5GHz as well. Perry.
Here's my report for 6.8.4 and Ryzen 7 7840HS: 1. Setting scaling_max_freq works, cool, but you cannot go below 544MHz. You can set 400MHz but the CPU will continue to jump to 544MHz, not a big deal. 2. Setting scaling_min_freq sort of works, the CPU _prefers_ to stay at this specified frequency but occasionally drops to 400MHz. Then, the CPU doesn't totally respect it, i.e. for values below 1.4GHz it stays around 1397MHz. The relationship is not linear, setting 4GHz results in the CPU preferring 3766Mhz. Or 2GHz -> 1982MHz. Not a big deal. Unlikely anyone would want to set the lowest frequency. 3. /sys/devices/system/cpu/amd_pstate/cpb_boost is missing altogether: # find /sys -iname '*boost*' [nothing] So, my only remaining question is where's boost support? Or it's not supported for all Zen CPUs? Thanks a lot for your work regardless!
Created attachment 306089 [details] attachment-6284-0.html Hello, Thank you for your message. I am currently out of the office from afternoon today to 4/8 for Chinese QingMing Festival. response will be delayed. Best wishes, Perry Yuan
Thank you, Perry, there's no rush! Not the last question, here's one more, I wrote about it earlier. cpuinfo_max_freq is invalid for multiple cores here as it often reports insane values: $ lscpu -ae CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ 0 0 0 0 0:0:0:0 yes 5137.0000 400.0000 400.0000 1 0 0 0 0:0:0:0 yes 5137.0000 400.0000 1394.3910 2 0 0 1 1:1:1:0 yes 6080.0000 400.0000 400.0000 3 0 0 1 1:1:1:0 yes 6080.0000 400.0000 400.0000 4 0 0 2 2:2:2:0 yes 5608.0000 400.0000 1396.2390 5 0 0 2 2:2:2:0 yes 5608.0000 400.0000 400.0000 6 0 0 3 3:3:3:0 yes 5293.0000 400.0000 400.0000 7 0 0 3 3:3:3:0 yes 5293.0000 400.0000 400.0000 8 0 0 4 4:4:4:0 yes 5449.0000 400.0000 1381.5620 9 0 0 4 4:4:4:0 yes 5449.0000 400.0000 1393.0980 10 0 0 5 5:5:5:0 yes 6080.0000 400.0000 1383.3900 11 0 0 5 5:5:5:0 yes 6080.0000 400.0000 1397.3979 12 0 0 6 6:6:6:0 yes 5764.0000 400.0000 1397.4200 13 0 0 6 6:6:6:0 yes 5764.0000 400.0000 400.0000 14 0 0 7 7:7:7:0 yes 5924.0000 400.0000 1396.0959 15 0 0 7 7:7:7:0 yes 5924.0000 400.0000 400.0000 5137MHz is probably the best my CPU cores can do. No way 6080MHz is possible. I wonder if you could fix it. HWiNFO64 reads maximum CPU cores frequencies correctly.
(In reply to Artem S. Tashkinov from comment #56) > Here's my report for 6.8.4 and Ryzen 7 7840HS: > > 1. Setting scaling_max_freq works, cool, but you cannot go below 544MHz. You > can set 400MHz but the CPU will continue to jump to 544MHz, not a big deal. > > 2. Setting scaling_min_freq sort of works, the CPU _prefers_ to stay at this > specified frequency but occasionally drops to 400MHz. Then, the CPU doesn't > totally respect it, i.e. for values below 1.4GHz it stays around 1397MHz. > The relationship is not linear, setting 4GHz results in the CPU preferring > 3766Mhz. Or 2GHz -> 1982MHz. Not a big deal. Unlikely anyone would want to > set the lowest frequency. > > 3. /sys/devices/system/cpu/amd_pstate/cpb_boost is missing altogether: > > # find /sys -iname '*boost*' > [nothing] > > So, my only remaining question is where's boost support? Or it's not > supported for all Zen CPUs? > > Thanks a lot for your work regardless! 1. please try to apply the two patches for your cpb testing. https://lore.kernel.org/lkml/cover.1711335714.git.perry.yuan@amd.com/ https://lore.kernel.org/lkml/Zfqv3ckVU4km+RLr@BLR-5CG11610CF.amd.com/ 2. are you testing under EPP driver mode? the 400MHz is the lowest freq, however it dose not mean the CPU will be keeping at 400MHz, it will wake up and idle and bump up frequency shortly according to the workload. you need to know, when the Core is idle, kernel will not get the realtime frequency by APERF/MPERF, cpufreq just show the lowest freq as 400MHz. It is not an issue. There is one idle frequency defined by power firmware, it is 1.4GHz for some client system, the lowest active frequency is not 400MHz, it is 1.4GHz. so you have no need to worry the 1.4GHz or 400MHz, it is not a problem. 3. the invalid max frequency value issue is caused by wrong highest perf value defined by pstate driver, I have been working a solution to fix that. with EPP driver mode, it will not cause any performance problem, just a little uncomfortable to see the wrong value listed. Perry.