Announcement

Collapse
No announcement yet.

Intel Core i9 12900K P-State Governor Performance On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel Core i9 12900K P-State Governor Performance On Linux

    Phoronix: Intel Core i9 12900K P-State Governor Performance On Linux

    Since Intel's Alder Lake launch one of the test requests to come in a few times has been about the Intel P-State CPU frequency scaling driver and how its performance differs with the various governor choices available for altering the CPU frequency scaling behavior. Now that Linux 5.16 stable is out and running in good shape on Alder Lake, here are some Core i9 12900K benchmarks looking at various CPU frequency scaling choices and their impact on raw performance as well as CPU thermals and power consumption.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Thanks. It would be great to see comparison against default Ubuntu 21.10 and 20.04 LTS governors.

    Comment


    • #3
      So intel_cpufreq perf seams to be much more efficient than p-state perf while simultaneously beeing on the same performance level making p-state powersave totaly useless. Or am I missreading it?

      Comment


      • #4
        Can someone explain or link different governor technologies?

        Comment


        • #5
          Hmm - to me the interest in any governor other than performance is not lowest consumption, but efficiency - meaning performance/W. With all the base data available I was hoping to see graphs that spell out / compare the setups for efficiency.

          Comment


          • #6
            Q: Why should Intel go see a doctor?

            A: Because their p-state is hotter than the rest.

            Comment


            • #7
              Given the individual graphs, I expected p-state powersave to consume noticeably less power than intel_cpufreq performance. I was quite surprised to read the overall-average graphs, showing intel_cpufreq performance to consume less power.

              Comment


              • #8
                Originally posted by mppix View Post
                Can someone explain or link different governor technologies?
                DuckDuckGo is your friend. But here are three pages that I found very helpful to understand CPU frequency scaling:





                Comment


                • #9
                  DuckDuckGo

                  However, do I get this right:
                  - P-state is an AHCI technology and a governor may or may not interface with them through required interfaces.
                  - Linux has the generic governors: schedutil and ondemand. They may use P-sates (infrastructure is being implemented if not already there). They already do for AMD processors.
                  - Intel P-state governors are independend from the generic governors (the AMD ones are not).

                  Comment


                  • #10
                    Originally posted by Eumaios View Post
                    Given the individual graphs, I expected p-state powersave to consume noticeably less power than intel_cpufreq performance. I was quite surprised to read the overall-average graphs, showing intel_cpufreq performance to consume less power.
                    Yeah, this has been my suspicion for a while now and therefore it's good to see it confirmed with hard data by Micheal.

                    But when pondering about it, it does make sense actually:
                    With the performance governor, your CPU is only faced with a binary choice - either go full speed on a task or idle in the deepest sleep-state possible, thus saving the most amount of energy & heat output.

                    Dynamic schedulers such as "schedutil" however have a far more complex choice to make:
                    Trying to second-guess the most 'optimal' frequency for any given task, which in real-world usage scenarios means constantly chasing behind ever-changing workloads while taking longer to complete them and use more power along the way - therefore being more often wrong than right, as seen with Michael's benchmarks.
                    (i.e. Trying to guess out of the CPU scheduler's a$$.)

                    Now, these benchmarks are the final nail in the schedutil coffin for me:
                    Even after all these years, it seems as though it simply can't be improved upon any further; so from here on out, I won't bother anymore evaluating it and just stick to the performance governor at all times.

                    But there is still one unfortunate idea that keeps nagging me:
                    The Steam Deck will be using schedutil by default, and I honestly can't see it perform any better on AMD's APU, because the decision-making logic is the very same flawed one we are witnissing here...

                    Anyhow, hopefully Micheal can be seeded with a Steam Deck by Valve, so we could get a definitive answer via benchmarks!

                    Comment

                    Working...
                    X