[RESPONDED] Linux amd_pstate scaling driver benchmarks

Framework Laptop 13 Linux
1

In the past few week I played a bit around with the Linux amd_pstate driver and scheduling in general on my Framework 13. I did some benchmarks to find out the optimal pstate and governor settings for different scenarios and now want to share my results with you.

Before you continue, if you have no idea what the hell the amd_pstate driver is read this great reddit post and this phoronix article first. Also have a look at the CPU frequency scaling entry on the Arch wiki and for in-depth information, consult the kernel doc.

First off, some details about my system:

  • System: Framework Laptop 13 (AMD edition)
  • CPU: AMD Ryzen 7 7840U
  • Memory: 2x32GB DDR5-5600MT/s
  • OS: Arch Linux
  • Kernel: 6.7.5.arch1-1
  • Power management: power-profiles-daemon

For benchmarking, I used the Phoronix Test Suite and ran a quite randomly assembled mix of multi and single core benchmark suites:

  • Multi core:
    • pts/openssl
      • RSA4096
      • SHA512
      • AES-256-GCM
      • ChaCha20-Poly1305
    • pts/stockfish
    • pts/m-queens
  • Single core:
    • pts/crafty
    • pts/compress-gzip
    • pts/encode-mp3
    • pts/encode-flac
    • pts/espeak

I ran the tests for every possible combination of pstate setting, CPU governor and ACPI platform profile (APP) setting and recorded the geometric mean of performance and power consumption for all tests. For the active mode, I also tested with every combination of energy profile preferences. Also, I run the test suites at night, so there should have been no relevant background noise.

The results were quite interesting. My main points of interest were performance, power consumption and performance per watt. For all those three points the results clearly shows that the most effective setting affecting those is the APP. The powersave governor can also make a great difference however. Thus I partitioned the results according to this and came up with four scenarios:

  • Performance: Best performance possible regardless of energy consumption/efficiency.
  • Balanced: Good balance between performance and energy consumption while also maintaining a good energy efficiency.
  • Powersave: Low energy consumption and maximum energy efficiency.
  • Extreme powersave: Save as much power as possible regardless of performance or energy efficiency.

As expected, for maximum performance the performance APP works best. Also guided works better than passive. A bit unexpected is that the schedutil governor actually beats the performance governor.

For the balanced scenario, also as expected the balanced APP works best. As for the governor, schedutil is a wise choice here since it offers the best results AND the lowest energy consumption. The pstate setting here does not make much of a difference but I’d vote for passive here since it offers better performance and power consumption together with the schedutil governor and the balanced APP.

For powersave, the best energy efficiency is achieved with the low-power APP in combination with the schedutil governor, but the least power is drawn with the powersave governor. However, the energy efficiency of the powersave governor is unacceptably bad so it it not an option here. The pstate mode also does matter that much here, but guided scores a bit better than passive so let’s go with it.

As mentioned above, despite the horrible efficiency the least energy is drawn with the powersave governor, which makes it a good candidate for extrem powersaving. Suprisingly, this works best combined with the performance APP and the passive governor.

If you want to have a look at the results for yourself you can find them in the attached analysis.ods file. Note that I had to change the extension to .stl as otherwise I wouldn’t be able to upload it. To view it, just rename it to analysis.odt.

That’s it. Thank you for reading. I hope my work was useful or at least interesting for you :).

EDIT: For those interested I thought I’d also share the raw results exported from Phoronix as HTML. Have a look at them here: raw_results_sanitized.min.html (again please remove the .stl extension I only put there to avoid upload restrictions).

3 Likes
2

Hi @null , thanks for taking time to share your benchmarks. :slight_smile:

1 Like
3

Did your kernel include the preferred cores patches? And the PPD patched multi-profile daemon required for epp and platform state setting?

4

I’m not sure where those differences can be seen in the data. Are they included in the spreadsheet?

Also, if I’m not mistaken, AMD recommends using active pstate mode on newer kernels, rather than passive. Is that something you tried as well?

5

active epp is what you will get unless you tuned the kernel param or custom compiled the kernel. I think this has been default since 6.6 to set it to active (mode 3) in kernel config.

You don’t want to use guided which is the most recent mode for machines which include EC hinting. For zen 3/4 desktop SKU’s guided might be a better bet as the mainboards won’t provide hints like they will(should) for mobile.

6

It seems that the OP used the standard Arch kernel 6.7.5, so , active should’ve been the default value of amd-pstate. However, unlike passive and guided, it was not mentioned in the post. Hence my question.

Although, perhaps passive and guided referred to something else, @null? Just trying to understand your testing setup.

7

I was using the standard precompiled kernel and PPD packages from the Arch repository. If they include them then yes, otherwise no.

Actually it is as simple as executing echo '<pstate_mode>' | sudo tee '/sys/devices/system/cpu/amd_pstate/status'

8

Did you have a look at the spreadsheet? Best result performance wise was pstate-guided_gov-schedutil_app-performance. Also the benchmarks for active mode are included, I just didn’t come to mention them anywhere because they did not perform that well.

9

PPD only now (0.20 - released a few days ago) sets the platform and epp hints properly, prior to this it doesn’t set platform and epp hints (you can do this manually via a sysfs poke) - so you’ll get broken behaviour.

Guided is not advised when you have a platform which provides hints from hardware/firmware.

You should basically use the Powersave governor and then set the epp/platform hints for pstate to work correctly.

10

That combination is basically just using schedutil rather than amd_pstate which is only used when powersave is active.

11

My apologies. I do see the labels for pstate-guided and pstate-passive in the file. I entrusted the initial analysis to ChatGPT, who, for some reason, ignored parts of the strings until specifically asked about them. It was assuring me that the file didn’t mention anything containing either “passive” or “guided” :slightly_smiling_face:

Unlike the other two modes, I don’t see the active pstate mentioned in the file. How do I find the related results?

12

I am sorry but my data does not agree with this at all. The best results performance AND efficiency wise were almost always delivered with the schedutil governor in combination with the guided mode for the amd_pstate driver.

No, the amd_pstate driver in passive or guided mode can be used with whatever governor you like. Please have a look at the resources I mentioned at the top of my post.

@Wrybill_Plover I have not explicitly labeled them, but the energy performance preference (EPP) settings are only available in active mode. So the entries starting with epp are those for the active mode.

13

Understood. Thank you!

14

Am aware; I use schedutils and guided on my Zen3/4 Workstations for that purpose.

What I am suggesting is that for mobile SKU’s the hints provided by the platform hardware should be preferred from a thermal/stress perspective if nothing else and so epp active should only ever be the driver used.

15

But wouldn’t the results of these benchmarks, performed on this specific mobile SKU and platform, suggest otherwise?