cat plus wildcard expansion will show the contents of any files matching the pattern. No need to try them one at a time.
then all i can suggest is once you get to the cpu0 level of the tree, you start looking in each folder you can.
or update your database and do a locate for scaling_driver
Kernel 6.4 will be feature complete for amd-pstate. By then all three modes will be supported i.e ‘amd_pstate=guided’, ‘active’ and ‘passive’
Kernel 6.3 supports ‘active’ and ‘passive’ modes.
I lost track of earlier kernels. Before 6.3, only passive mode (which is now named of) supported. Also depends on versions of patches applied by distributions, there might have different ways to support the passive mode.
Perhaps you blacklisted ‘acpi-cpufreq’ driver? Just my guess. Otherwise your system setup is very weird.
When ‘amd-pstate’ is enabled, it’ll be automatically loaded over ‘acpi-cpufreq’. When ‘amd-pstate’ fails to load, the kernel will automatically faill back to ‘acpi-cpufeq’. If you blacklist ‘acpi-cpufreq’, nothing will be loaded which is a very bad state.
Whew, OK. What a wild ride.
In addition to the above symptoms, I also noticed that my cores were idling down to 3400 MHz, which seemed a bit high. And my test bench with an Asus Pro WS X570-ACE with a 3900X is having all of the same issues as well (and idling down to 3700 MHz, even in Windows).
I went back into the BIOS, loaded optimal settings, then did a very basic config just to get my system posting again. When I got back into Linux, I noticed right away that my cores were idling down to 2200 MHz (IIRC) and—et voilà!—/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver was showing acpi_cpufreq again.
So then I moved on to the next phase: trying to figure out which wacky BIOS setting I enabled that basically broke a big piece of ACPI. After some trial and error I found the culprit… I had enabled X2APIC on both X570 systems a few weeks ago to see if it was stable and working well enough to daily drive. I guess I didn’t look closely enough!
Now I can easily enable amd_pstate and it works as expected. And my cores are idling down to 550 MHz, which is great!
I hadn’t initially and then did so after @xyz linked that Phoronix article. Even after removing it again I still couldn’t get acpi_cpufreq or amd_pstate to load.
Anyway, thanks everyone for chiming in with ideas, and sorry that it ultimately boiled down to my own stupidity (and desire to test bleeding-edge features). To anyone reading this in the future: if ACPI is completely broken on your AMD board, disable X2APIC!
2 Likes
Congrats on getting amd-pstate to work finally.
Good to hear there is such a feature (and associated bug). lol
Now that I know what to Google…
1 Like
I have read the official documentation, but I am still not entirely sure how active and passive mode differ. Does anyone here has a good understanding of this?
Okay, the active mode does not work for me since it is available from kernel 6.3 and above while I am on 6.1 still.
With amd-pstate driver in passive mode, I have a multi-core score of 7701 in Geekbench 6, while with the default acpi-cpufreq driver I reach 13324 point in the multi-core benchmark. For now I have reverted the changes. There seem to be problems with the pstate driver still and since there is next to none documentation about it, I will refrain from using it for the time being.
Okay so with amd_pstate=passive you have to manually set the governor. With the default schedutil performance tanked, with ondemand it is a little below the acpi-cpufreq driver and set to performance it is even a little faster then acpi-cpufreq.
The notes from the guided-autonomous patch series have been the most helpful to me so far:
From ACPI spec below 3 modes for CPPC can be defined:
Non autonomous: OS scaling governor specifies operating frequency/performance level through
Desired Performanceregister and PMFW follows that.Guided autonomous: OS scaling governor specifies min and max frequencies/ performance levels through
Minimum PerformanceandMaximum Performanceregister, and PMFW can autonomously select an operating frequency in this range.Fully autonomous: OS only hints (via EPP) to PMFW for the required energy performance preference for the workload and PMFW autonomously scales the frequency.
Currently (1) is supported by amd_pstate as passive mode, and (3) is implemented by EPP support[2]. This change is to support (2).
In guided autonomous mode the min_perf is based on the input from the scaling governor. For example, in case of schedutil this value depends on the current utilization. And max_perf is set to max capacity.
1 Like
Linux 6.4 released. amd-pstate driver is finally mainlined with ‘guided autonomous mode’. Did some chores with my little mATX box:
Zen2 seems to be in good shape after a long run of 4 years. It should have been the case on the first day!
Any ‘major’ hardware features out there still left un-explored/un-used ? One thing comes to my mind is AVIC.
AVIC should reportedly improve performance of passthrough PCIe devices. There was a popular Reddit post about it. Once upon a time, it worked for me in some older kernel versions. Stopped working ever since then. The developer world seems to have little attention about AVIC, which is begging the question of its usefulness or is simply lacking awareness of this hardware feature.
2 Likes
Passed by this thread while messing around with active and guided mode in 6.4 and felt the need to write down my experience w amd-pstate.
I used a Ryzen 3700X until i needed more cores and then bought a used 5950X. The power usage increase moving from away from a 65W TDP cpu was a bit higher than expected, and since the pc is on 24/7 I thought it might be agood idea to start messing around with limiting core frequencies and using cpusets to restrict which cores are used for what, with the goal to achieve a decently snappy desktop experience while using as little power as possible.
Interestingly, with all the extra cores I didn’t have to use the boost frequencies as much and power usage actually went down compared to the 3700X. Usually I’m around 125-140W as measured by the PSU. (40-55W used by both 3080 and more recently 4090, not to happy about that compared to the ~20s W used by my older GTX670).
Now trying out the active and guided modes they’re very boost-happy, even with the powersave profiles, and I ended up around 160-200W instead.
Ryzen will happily consume as much power as it can as long as there is thermal and electrical headroom to do so, even if it doesn’t actually need that much power to hit a certain frequency. The solution to rampant power consumption is to lower those limits: PPT, TDC, and EDC. SVI2_P_Core on my 5950X system used to peak around 135W under sustained multicore loads, now it’s around 75W with very little performance impact.
135W, amd_pstate=guided:
75W, amd_pstate=guided:
If you’re interested in doing something similar, you can try enabling ECO mode. However, on my two Asus X570 boards, that seems to set the limits too low; SVI2_P_Core peaks around 35W in this configuration. My solution is to disable PBO Limits, which seems to leave PBO enabled (with my curve, boost offset, etc.) but uses the default limits for the processor.
As far as this goes, I think the problem with amd_pstate=guided is that Linux scaling governors are currently somewhat limited in their ability to manipulate the minimum/maximum performance registers as described above. Per the last bit of the patch series notes:
In guided autonomous mode the min_perf is based on the input from the scaling governor. For example, in case of schedutil this value depends on the current utilization. And max_perf is set to max capacity.
So there’s no apparent way to lower max_perf for a process (group) or a list of CPUs in this mode.
Fully-autonomous mode (amd_pstate=active) might be the better fit for your use case. From the Arch wiki:
The most important feature of active governing is that only two governors appear available,
powersaveandperformance. They do not work at all like their normal counterpart, however: these levels are translated into an Energy Performance Preference hint for the CPU’s internal governor.[…]
It is possible to select in-between hints with the sysfs interfaces available. […] One can also pass a number between 0 (favor performance) and 255 (favor power).
So you should be able to use this mode and then set EPP hints to a value 0–255 for each CPU, then assign each process to a list of CPUs to get the desired scaling behavior for that process. (And maybe this is what you’re trying to do already, but until you get power consumption wrangled at a high level this probably won’t help that much.)
For 5950x, going from 160W to 200W…? I would bet it has little chance to do with switching to amd-pstate driver.
For 5950x, going from 135W down to 75W, only losing 5% multi-threaded performance in GB6 is amazing. 
Btw, Linux 6.5 will come with amd-pstate in ‘active’ mode as default on support Zen family processors!
Other benchmarks will show different results. Geekbench tends to be sensitive to memory throughput and/or latency. But even XMRig running RandomX gets ~17KH/s at 75W vs ~18KH/s at 135W.
It’s basically the same thing folks are discovering about Ryzen 7000X: out of the box they seem to be quite power hungry, but enabling one of the ECO modes can get you ~95% of the MT performance for ~60% of the power budget.
One thing to note, though… this is just the power consumption of the cores reported by the zenpower kernel module. The difference at the wall is probably less stark.
Near the end of voltage-frequency curves, both AMD and Intel processors climb up steeply. It’s dictated by physical limits of process technologies on one hand. On the other hand, by the tradition of PCs for consumers/gamers both vendors squeeze the last bit of juice in their default settings. Such practice can’t be justified IMO. But well, in a world of competing whose epenis is bigger every drop of juice counts.
GB6 is a good quick & dirty test for an all-round set of workloads. Perhaps it’s more meaningful to everyday use than, say, Cinebench which every YouTube reviewer seems to run.
1 Like
Surprise. Surprise. The next excitement on amd-pstate just happened.
The Linux team from AMD posted a “preferred cores” enhancement [0] to the amd-pstate driver. This enhancement will take further advantage of CPPC support introduced since Zen 2. It will do
- take static ranking of cores’ silicon quality into account and schedule tasks to the best cores to get the work done
- take #1 into account as well as dynamic conditions (such as highest achievable freq of cores for the next time slice) into account and schedule tasks for the best available cores
I would think this enhancement brings Linux on Zen 2 and onwards to be better than Windows finally if not on par. Four years late as I’ve saying but seems AMD picks up the moment in Linux every week and month…
The current critics on this change are all on coding styles. Has yet to see one challenge on the correctness of the functionality.
I’ve been running Linux 6.4.8 with this patch applied for two days. So far so good. It will be quite a challenge to create a test scenario to show performance difference. So you’ll need a little faith in it just making things better. lol
I have a modified patch for Linux 6.4.x. If there is interest, I can share here.
2 Likes
I wish there was a way to just use the Mainline Kernel PPA to get the newer kernels on my Ubuntu 22.04.3 LTS installation.
But I have found it impossible to install anything newer than 6.4.3 kernel because all the later kernels have been compiled with GCC-13 and the 22.04.3 distro only comes with GCC-12 and you get a DKMS error when compiling the Nvidia 535 drivers into the kernel.
I really need the 6.5 kernels to get proper sensor support for my 7950X. I’ve asked for solutions but have been told the only solution is to compile the kernels myself. I haven’t gotten to that skill level yet.
I guess I will just have to wait for the Ubuntu 23.10 distro release in October to get the 6.5 kernels and the GCC-13 compiler.
Yes, please!
Here you are~ Pls see attached. “amd_pstate prefcore” patch for Linux 6.4.x.
To enable this feature at runtime, append 'amd_prefcore=enable' to Kernel command line.
To check at runtime if this feature is enabled:
root@zen:~$ cat /sys/devices/system/cpu/amd_pstate/prefcore_state
enabled
amd-prefcore.patch (20.6 KB)
Sweet. It applied cleanly to 6.5-rc5; hopefully it will compile and I can give it a try. Thanks @vic!
ETA: It compiled and booted, and I’ve confirmed that it’s enabled. I’ll use it for a few days and hopefully be able to give some subjective feedback. Geekbench 6.1.0 before and after
1 Like