Announcement

Collapse
No announcement yet.

Significant Performance & Perf-Per-Watt Gains Coming For Intel CPUs On Linux Schedutil

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

  • #11
    Originally posted by geearf View Post

    You have to either disable pstate or switch it to passive, if not you have no cpufreq governor.
    Originally posted by skeevy420 View Post

    I use the "cpupower" package and its systemd unit. It's configured under "/etc/default/cpupower". I'm including mine because I've added some notes from the man pages it says to reference that only contains relevant information on the perf_bias setting. On my Manjaro box, enabling either of the smp_* and mc_* settings prevents it from working so I don't use them. Using 0 on the perf_bias option is the same as doing the command I posted above.
    Big thanks to both of you. I'm finally up and running. The intel_pstate=passive was what I was missing! I did some light gaming and multitasking on the desktop and schedutil was very smooth. This is with the patches Michael posted about so I can't compare it to without but I'm impressed so far. Gonna try it out for a bit.

    Code:
    ~ ❯ sudo cpupower frequency-set --governor schedutil
    Setting cpu: 0
    Error setting new values. Common errors:
    - Do you have proper administration rights? (super-user?)
    - Is the governor you requested available and modprobed?
    - Trying to set an invalid policy?
    - Trying to set a specific frequency, but userspace governor is not available,
       for example because of hardware which cannot be set to a specific frequency
       or because the userspace governor isn't loaded?
    ~ ❯ sudo cpupower frequency-set --governor powersave
    Setting cpu: 0
    Setting cpu: 1
    Setting cpu: 2
    Setting cpu: 3
    ~ ❯ sudo cpupower frequency-set --governor performance
    Setting cpu: 0
    Setting cpu: 1
    Setting cpu: 2
    Setting cpu: 3
    ~ ❯ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
    intel_pstate
    ~ ❯ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    performance
    ~ ❯ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors
    performance powersave
    performance powersave
    performance powersave
    performance powersave
    After adding intel_pstate=passive to GRUB and rebooting:

    Code:
    ~ ❯ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors
    conservative ondemand userspace powersave performance schedutil
    conservative ondemand userspace powersave performance schedutil
    conservative ondemand userspace powersave performance schedutil
    conservative ondemand userspace powersave performance schedutil
    ~ ❯ sudo cpupower frequency-set --governor schedutil
    Setting cpu: 0
    Setting cpu: 1
    Setting cpu: 2
    Setting cpu: 3
    ~ ❯ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
    intel_cpufreq
    ~ ❯ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    schedutil

    Comment


    • #12
      Maybe I've missed a point when reading the article, but the general behavior seems to improve all X86 CPUs, correct? Why are Intel CPUs pointed out then?

      Reading the last couple of months on CPU tweaking improvements, I got the impression, that AMDs Zen 2 cores benefit from proper transient response on boost behavior by keeping boosting cores in the boosting state as long as the thermal limit isn't hit as well as keeping a task on the same CCX/CCD that is already processed as well as inter-core processing to switch between "hot" and "cold" cores as long as the required data is still in the L1/L2 cache.

      Is there a bias towards Intel CPUs or is the work on AMD CPUs just ahead?

      The last thing Linux needs are biased performance governor, so I'll just ask nicely if there is a bias.

      Comment


      • #13
        Originally posted by Shevchen View Post
        Maybe I've missed a point when reading the article, but the general behavior seems to improve all X86 CPUs, correct? Why are Intel CPUs pointed out then?

        Reading the last couple of months on CPU tweaking improvements, I got the impression, that AMDs Zen 2 cores benefit from proper transient response on boost behavior by keeping boosting cores in the boosting state as long as the thermal limit isn't hit as well as keeping a task on the same CCX/CCD that is already processed as well as inter-core processing to switch between "hot" and "cold" cores as long as the required data is still in the L1/L2 cache.

        Is there a bias towards Intel CPUs or does the work on AMD CPUs just ahead?

        The last thing Linux needs are biased performance governor, so I'll just ask nicely if there is a bias.
        It relies upon some Intel specific MSRs.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #14
          Originally posted by Michael View Post

          It relies upon some Intel specific MSRs.
          Gotcha, thx.

          Comment


          • #15
            Dynamic power consumed by CPU = frequency*capacitance*square(voltage), with the constraint/relationship that an increase in frequency requires an increase in voltage. Avoiding turbo boost frequencies when running on battery means lower voltage requirements.

            https://en.wikipedia.org/wiki/CPU_po...pation#Sources

            Comment

            Working...
            X