AMD P-State EPP Performance With EPYC On Linux 6.3

[phoronix]

Phoronix: AMD P-State EPP Performance With EPYC On Linux 6.3

Among the many new features coming in Linux 6.3 -- including many AMD additions -- is the AMD P-State EPP "Energy Performance Preference" support being merged for modern Ryzen and EPYC systems. AMD P-State EPP can further help tune the performance and power efficiency of AMD Linux systems beyond the existing basic AMD P-State driver support and address some existing deficiencies. Here are some benchmarks of the AMD P-State and ACPI CPUFreq driver configurations benchmarked on an EPYC Milan-X server with the in-development Linux 6.3 kernel.

https://www.phoronix.com/review/linux-63-amd-epyc-epp

[edwaleni]

Can I assume that I would expect a similar result on AMD 6000/7000 mobile APU's?

Most datacenters I work with (that would have a EPYC system tested) suppress the power management features because they want max performance at all times, unless they energy shift their workloads,

The systems that I would expect any enhanced power management to have the largest benefit would be in the mobile space where battery behavior is paramount.

[Michael]

Can I assume that I would expect a similar result on AMD 6000/7000 mobile APU's?

Most datacenters I work with (that would have a EPYC system tested) suppress the power management features because they want max performance at all times, unless they energy shift their workloads,

The systems that I would expect any enhanced power management to have the largest benefit would be in the mobile space where battery behavior is paramount.

I have benchmarks running on PRO 6850U at the moment.

[ptr1337]

Michael, how you were able to set:
CPU gov performance + balance_performance

At me this is not working at all, did you mean powersave + balance_performance?

balance_performance does only work, together with the powersave governer.

[Michael]

Michael, how you were able to set:
CPU gov performance + balance_performance

At me this is not working at all, did you mean powersave + balance_performance?

balance_performance does only work, together with the powersave governer.

It worked as stated, and just double checked the (automated) system table and indeed was set. Was working fine on my system at least, maybe some firmware differences or the like with your platform.

[willmore]

Can someone help me understand why anyone would want to use this? "I spent 100K for a server and this setting lets me make it run as fast as a cell phone. Genius!"

[edwaleni]

Can someone help me understand why anyone would want to use this? "I spent 100K for a server and this setting lets me make it run as fast as a cell phone. Genius!"

Some companies have ESG requirements which demand that their compute has to be able to scale down when demand warrants it so as to stop climate change.

Some companies do energy based load shifting, they move compute around the globe to get the best bang for the buck depending how much their power costs are.

Some companies have applications that have low demand during off hours, so they aggregate all that demand into hosts with aggressive P-States to save money and move them back to high performance when demand requires it.

[Eumaios]

The good news is, no surprises in the results: use more power, get more performance. But I'm surprised how close the results are; AMD has really improved their frequency scalers.

For best outright performance, amd_pstate_epp performance balance_performance seems best. For best efficiency, amd_pstate_epp powersave balance_performance seems best. But the differences between them are slight!

Typo:

performance s a result

[Anux]

Whoa, cpufreq perf is doing some serious overclocking: 8 GHz on a server CPU, not bad ...

Atleast amd_pstate_epp isn't worse than the older shedulers, it even seems to win in efficiency which was the realm of cpufreq perf for a long time.

[yump]

The good news is, no surprises in the results: use more power, get more performance. But I'm surprised how close the results are; AMD has really improved their frequency scalers.

In CPU-bound benchmarks, anything other than extremely close results means something is wrong with one of the governors. A CPU frequency governor is only supposed to slow down the CPU if the workload spends time waiting on I/O. Ideally, that inlcudes every form of predictable I/O that the kernel knows about. Disk and network, but also less obvious things like the display refresh and mouse polling rates.

The hard case is when the workload is I/O bound for some application-level or human-level reason invisible to the kernel. Like if your service's latency SLA is 300% higher than current response time, but you provisioned a faster CPU to handle peak usage. Or if the 100% CPU-using video render only needs to finish before 9:00 AM, and there's no benefit to completing it sooner. Then it's a policy matter, and you're supposed to use uclamp:

https://lwn.net/Articles/762043/

https://www.kernel.org/doc/html/latest/scheduler/schedutil.html#uclamp