AMD P-State Preferred Core Handling Being Enabled For Linux

[phoronix]

Phoronix: AMD P-State Preferred Core Handling Being Enabled For Linux

A new set of patches have been posted for the Linux kernel that implement AMD P-State Preferred Core handling for the amd-pstate driver...

https://www.phoronix.com/news/AMD-Preferred-Core-Linux

[tildearrow]

Hit the lever for a chance to get a CPU with all cores able to reach max frequency.

[avis]

Hit the lever for a chance to get a CPU with all cores able to reach max frequency.

This patch is not about reaching the max frequency, x86 CPUs already do that.

It's about moving tasks to best idle cores in order to finish them faster.

[Anux]

Great, I'm in the process of optimizing my 5700G. Found smartshift in the BIOS which essentially lets you configure custom long, mid and short term powerlimits and under CPPC there was the option to enable preferred cores which had no messurable impact on anything. Now I know why.

I guess this feature will only work in the newest 6.6 kernel? Or could I set this kernel option with 6.4 already? pstate=active works and has just the slightest impact on performance, maybe with this PrefCore it would have a bigger impact?

It's about moving tasks to best idle cores in order to finish them faster.

Neither. It's about different cores that can reach different max freq limits under different temp/power conditions. The CPU will tell the OS which core has the best potential to clock high and the OS can prefer this core for high pressure tasks. Or if you use power-saver profile than the OS gets the most energy efficient cores to shedule it's tasks.

[skeevy420]

Hit the lever for a chance to get a CPU with all cores able to reach max frequency.

More like "Send task X to cores 34-83 because they run the fastest." Basically, this is AMD's solution to unoptimal binning, CPUs with hundreds of cores, and industrial waste. Instead of selling 128 cores that are guaranteed to hit 4.8Ghz they can sell 128 cores that are guaranteed to hit 4.4Ghz...but are designed to hit 4.8Ghz or higher. With the former solution they'd have to swap cores until they got a super binned monster. With preferred cores, they don't have to have as high of binning tolerances and can tweak their marketing to adjust....and when people get stuff that can overclock massively it gives AMD free press. Because of lower tolerances they might be able to have less product lines.

[Zeioth]

All the 3 kelnel options to enable it, in case someone is interested in testing it

amd_pstate.shared_mem=1 amd_prefcore=enable initcall_blacklist=acpi_cpufreq_init

Edit: I'm testing on a Zen3 7950X, so make sure your cpu supports P-state before enabling it, it at least leave a kernel without the parameter so you can revert easily if necessary.

[emansom]

Great, I'm in the process of optimizing my 5700G.
...

Here's two other tips:

Despite what all reviewers say: don't overclock memory past the point where it sends more than 1,25V to the SoC. As the chip will degrade beyond that point. The safest bet for Zen 2 and Zen 3 remains 3200Mhz.

The default AMDGPU and Mesa interaction within Linux also by default set the GPU clock way too high way too fast for too long, even while idleing GNOME/KDE usually the clock speed is set to max forever: wasting energy and decreasing the longevity of the chip. Look into tuning the AMDGPU Power Profile Mode through the /sys interface to resolve this. nvtop and radeontop can be used to monitor clocks.

[MastaG]

Imo, these are the things that should be in place before a product goes to market.
The 3000 series are pretty old by now and setting the fastest cores as the default ones definitely helps in quite a few scenarios.
Even if it lands for linux 6.7, it will probably not be enabled by default before 6.8 or 6.9...

[agd5f]

The default AMDGPU and Mesa interaction within Linux also by default set the GPU clock way too high way too fast for too long, even while idleing GNOME/KDE usually the clock speed is set to max forever: wasting energy and decreasing the longevity of the chip. Look into tuning the AMDGPU Power Profile Mode through the /sys interface to resolve this. nvtop and radeontop can be used to monitor clocks.

Not true. The SMU on the GPU manages the GPU clocks and adjusts them dynamically based on load. If the GPU is idle, the clocks are reduced. The memory clock may be kept high in some cases, depending on the monitors and whether or not the blanking periods are long enough to reclock memory without causing artifacts on the screen, but for most monitors it should not be a problem.

[emansom]

Not true. The SMU on the GPU manages the GPU clocks and adjusts them dynamically based on load. If the GPU is idle, the clocks are reduced. The memory clock may be kept high in some cases, depending on the monitors and whether or not the blanking periods are long enough to reclock memory without causing artifacts on the screen, but for most monitors it should not be a problem.

The default configuration of Mesa and AMDGPU yield the experience I described. Mesa could implement more to mitigate issues with the out-of-the-box power hungry SMU settings, for example.