I think your observation makes lots of sense, especially for those overclock at the brink of crash…
amd_pstate with “preferred core” feature changes the dynamics of thermal & power distribution when compared to simply amd_pstate or acpi_cpufreq.
I also observed differences in CO stability between windows and Linux (before P-state), with Linux being more ‘stable’(?). P-state + preferred core will bring Linux closer to windows in this respect.
It makes a lot of sense; from what I can tell, the AMD way of power optimization is to have cores essentially run either at the maximum clockspeed or minimum/parked, rather than the inbetween states, which is very different from the slower frequency ramp and rolloff of the standard ACPI mode.
It would indeed expose instability with transients and voltage fluctuations. I used to get this with setting idle and load clock times with PhenomMSRTweaker on a 960T as well, especially with lower idle voltages when coming off a heavy load.
1 Like
I think this is trash talk.
I found Windows was more stable too (e.g. running Prime95 tests). I also found Windows cheating or perhaps AMD’s driver/software cheating.
Linux is more faithful in respecting your UEFI settings but seems Windows is not.
Open up Zenmonitor and watch the clockspeeds on the cores. Even idle, you’ll see a lot of max or near max, and a lot of dead idle, rather than the inbetweens common on ACPI.
It can be freely observed, though it’s possible it’s an artifact of the reporting process.
I think this is more an artifact of acpi-cpufreq being designed around older Intel processors and never (really) being updated for newer Intel processors and Zen. Modern Intel processors use intel_pstate instead to get the frequency scaling behavior you describe. Zen processors can now use amd_pstate={active,passive,guided} instead, with amd_pstate=active becoming the default in 6.5+ kernel.
ETA: FWIW, I’m seeing good scaling behavior on my Ryzen 9 5950X with amd_pstate=active. Many cores are idle at 550, a few cores are hovering around 3600, and a few cores are actively scaling between 3600 and 5000. I suppose you could argue that there should be more scaling between 550 and 3600—maybe I need to tweak C-states in the BIOS?—but it’s still a huge improvement over acpi-cpufreq.
The behavior described is using amd_pstate= instead of acpi. Perhaps that’s where the confusion has come in?
ACPI produces the slower clock ramp of classical power saving architecture, whereas amd_pstate= produces the more modern race-to-halt behavior, the later of which causes larger transient spikes and drops from faster/steeper clock and voltage shifts, introducing periods of higher and lower voltage swings at a given clockspeed, introducing the described instability.
A slower clockspeed ramp is more stable when using lower/more tightly tuned voltage settings, because the variation between two adjacent voltage states ends up lower.
Hmm, no, see my edit above. Maybe it’s a board difference or AGESA difference? Different implementations of CPPC? I’m on an Asus ProArt X570-CREATOR and AGESA 120A. It would be useful if we could measure and compare actual real-world scaling and voltage behavior instead of trading anecdata. ETA: It should be noted that I’m using the prefcore patch.
Some months ago, when using an older version of AMD pstate, I actually could observe highest-clock frequently reporting 4.95ghz at idle, with most cores parked. The behavior may have changed more recently, but it’s definitely a much faster clock ramp and race-to-halt power strategy, which was the point of the original post. That is what amd_pstate is supposed to do.
Unfortunately, amd_pstate hasn’t been working maybe at all for me lately, so I can’t provide screenshots or video at this time. Hopefully 6.5 fixes it.
edit: I made a typo when fixing kernel boot params to add poll queues which is why it was broken. Now observing the same behavior as some months ago, reconfirmed. Race-to-halt. 4.95ghz highest frequency with little system load. Not quite idle, steam is doing something in the background, but it’s easy enough to see the race-to-halt behavior and clocks jumping between 0.55(halted) and 4.95(max load, max voltage).
Not sure where to upload ~1mb of video to showcase the behavior, but if you set polling freq in zenmonitor to 50ms, you should see just how it can jump between 0.55 and 3~5ghz and back down again very frequently, sometimes only jumping between 0.55 and fmax on
one core over and over.
video
ah, there’s an upload button here. okay. time to see what actually uploads.
Not the best sample as it’s mostly going idle to ~3.5 here mostly, but it demonstrates the race to halt behavior of amd-pstate well enough. I have also observed jumping between 0.55 and 4.X in the same time frame, I would assume fmax or close to it.
corectrl max clock readouts for idle system. You can see the sharp spikes, updates are 500ms here. Not sure I can speed that up in this one. The system prefers to clock one core up as fast as it can and complete tasks in order to race to halt here too. Very steep voltage fluctuations too, of course.
Interesting p-state code review / testing on a 7950x
2 Likes
Can you summarise what bugs the YouTuber claimed to have found?
Sorry to admit… when I saw the video is near an hour long, I didn’t watch.
I did try to skim through the first 10 minutes. I saw on his screen that he seemed to refer to these lines of codes:
+ if (!prefcore_enabled)
+ WRITE_ONCE(cpudata->highest_perf, AMD_CPPC_HIGHEST_PERF(cap1));
+ else
+ WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
He claimed that the logic was reversed and nobody caught it in code review. Other than this, are there any other “bugs” he claimed to find in the video?
Personally I don’t understand the amd-pstate code at all nor I have insider info about the zen chips that how it works.
But my hunch …after reading the codes… is with the AMD guy, I believe the AMD guy is right to begin with.
You basically paraphrased what the YouTuber claimed.
But didn’t explain why his claim is right.
He is correct. The original code uses reverse logic incorrectly.
If you watch near the end and scan for the screenshot thumbnail he essentially removed one character.
to this:
the exclamation point proclaims “if prefcore NOT enabled”
The code did essentially nothing and left the perf score stock for each core. Never looked for the two to four preferred cores that are fused to indicate the best silicon cores.
You are again paraphrasing the YouTuber’s claim. Just rehash it in a different way like alkafrazin did.
But you did not explain why his claim is right either. The mechanics of the code is not the issue for me. I’ve been a C programmer for a long long time…
The key is for the case of “prefcore_enable is true”, the assignment should be the value as claimed by the YouTuber. Why? You have to explain this in order to agree with the YouTuber he is right.
I explained his claim in my original post, and it seems both of you didn’t catch it:
Also his code change suggestion was picked up and merged into the latest 6.6 kernel git pull. I didn’t look at the new code by Meng Li.
Just the header title info in the discussion list.
Oh…do you have a link to this?
From Phoronix article earlier today.
- A fix to the amdp-state-ut code to return the correct highest_perf value. Due to platforms supporting AMD Preferred Core handling, the amd-pstate-ut driver to this point didn't return a properly handled value.
Modify AMD pstate driver to return the highest_perf value (Meng Li)
What made you think this is relevant to the discussion - the claim made by the YouTuber?
Btw, is this your own imagination? Or it’s the YouTuber’s claim in his video that his finding has been merged?
I said I didn’t review the actual code change by Meng Li. Haven’t found it yet.
So I don’t know if the code change was what the YT did or not.
All I’m going by is the discussion title of the code change saying that up to this point the preferred code values were never returning the proper values.
That aligns with what the YT claimed and demonstrated in his video.
It’s not related at all. And you should not draw any conclusion and stated as fact like you just did a few post back:
“Also his code change suggestion was picked up and merged into the latest 6.6 kernel git pull.”
The above statement is not true at all from my fact-check that I just did.