Announcement

Collapse
No announcement yet.

CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17

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

  • CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17

    Phoronix: CPUFreq Ondemand Could Be Faster, Use Less Power With Linux 3.17

    Improvements to the CPUfreq ondemand governor could lead to faster performance in low to medium workloads with the Linux 3.17 kernel while also consuming less power overall...

    http://www.phoronix.com/vr.php?view=MTc0NzA

  • #2
    Thats very nice. Good Work!

    Comment


    • #3
      Is there a workaround we can use right now to replicate this?

      Comment


      • #4
        fjiowewefiojwefjiowefiojowefjiowiefjowefijefjfjiew jfowiejwoeijwefoijwefoijwefoijwefji

        Originally posted by Alejandro Nova View Post
        Is there a workaround we can use right now to replicate this?
        You can't wait until kernel 3.17 to have a 6% increase in speed??..
        I think a workaround until then would be go buy a faster processor..

        Comment


        • #5
          Originally posted by Baconmon View Post
          You can't wait until kernel 3.17 to have a 6% increase in speed??..
          I think a workaround until then would be go buy a faster processor..
          Go performance governor and tweak triggers.

          It will also help with multi threaded games. Where ondemand seriously underperformed by setting too low frequencies, then moving threads between cores, then increasing frequencies, then moving threads, then...


          Go performance governor (especial if You already use Intel P-State driver)

          Comment


          • #6
            Originally posted by przemoli View Post
            Go performance governor and tweak triggers.

            It will also help with multi threaded games. Where ondemand seriously underperformed by setting too low frequencies, then moving threads between cores, then increasing frequencies, then moving threads, then...


            Go performance governor (especial if You already use Intel P-State driver)
            Maybe someone can help me understand. Why not use highest frequency when needed and when the job is finished fall back to lowest frequencies?
            The ones in between would only be necessary if some synchronisation/io wait occurrs frequently.
            Would it not make sense to calculate a per frequency workload? and when it reaches a certain point it shall jump to a higher/lower state? or is there too much hysteresis?
            How is it done now? i didnt quite get it.

            Comment


            • #7
              Originally posted by jakubo View Post
              Maybe someone can help me understand. Why not use highest frequency when needed and when the job is finished fall back to lowest frequencies?
              The ones in between would only be necessary if some synchronisation/io wait occurrs frequently.
              Would it not make sense to calculate a per frequency workload? and when it reaches a certain point it shall jump to a higher/lower state? or is there too much hysteresis?
              How is it done now? i didnt quite get it.
              The issue with jumping between the max and min frequencies is that it assumes the job is cpu-bound and finishes quickly. Consider something like video playback, where you have a moderate but continuous load for a long period of time. There is no advantage to using a higher frequency, and it just consumes more power; the ideal frequency is the minimum which can meet the performance requirements (i.e. no dropped frames).

              Scaling the frequency proportional to the load has the nice property that it introduces a feedback loop - if you scale the frequency high enough the cpu usage will drop below 100% (most loads are not entirely CPU bound), and you reach a steady state.

              Comment


              • #8
                but if you just said

                if currentCPUload > upper boundary (for instance 95%) --> go step up
                if currentCPUload < lower boundary (for instance 60%) --> go step down

                wouldnt it suffice?
                or would it be jumping too much between states?

                Higher frequencies are more efficient right? (less total memory refreshes per task and sharper signal edges)

                Comment


                • #9
                  Question: Why would one still use the CPUFreq govenors on a SNB+ Core i7 machine while Intel provides their P-State govenor that supposedly run much more efficient on their CPUs? What is the advantage?

                  Comment


                  • #10
                    Originally posted by jakubo View Post
                    but if you just said

                    if currentCPUload > upper boundary (for instance 95%) --> go step up
                    if currentCPUload < lower boundary (for instance 60%) --> go step down

                    wouldnt it suffice?
                    or would it be jumping too much between states?

                    Higher frequencies are more efficient right? (less total memory refreshes per task and sharper signal edges)
                    The approach you suggest would be less responsive. i.e. it would take more iterations to reach the desired state. Hysteresis (jumping between states) would be a problem too, depending on how you tuned it.
                    I suspect the reason the algorithm is designed that way is that it makes it much easier to apply control theory to its design, since the definition does not rely on current state.

                    Originally posted by saski View Post
                    Question: Why would one still use the CPUFreq govenors on a SNB+ Core i7 machine while Intel provides their P-State govenor that supposedly run much more efficient on their CPUs? What is the advantage?
                    The CPUFreq governors offer more control. That said, according to this appears that even if CPUFreq specifies a certain frequency, the governor built into the CPU treats it as a suggestion only.

                    Comment


                    • #11
                      Originally posted by Baconmon View Post
                      You can't wait until kernel 3.17 to have a 6% increase in speed??..
                      I think a workaround until then would be go buy a faster processor..
                      I was referring to governor tweaks. I'm using currently 2 sets of tweaks, but they might be outdated.

                      First set:

                      Code:
                      /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 6
                      /sys/devices/system/cpu/cpufreq/ondemand/up_threshold = 35
                      /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load = 1
                      
                      #Battery
                      /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias = 200
                      Second set (battery only)

                      Code:
                      /sys/devices/system/cpu/cpufreq/conservative/up_threshold = 98
                      /sys/devices/system/cpu/cpufreq/conservative/down_threshold = 95
                      /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor = 7
                      /sys/devices/system/cpu/cpufreq/conservative/ignore_nice_load = 1

                      Comment


                      • #12
                        Originally posted by rdnetto View Post
                        The approach you suggest would be less responsive. i.e. it would take more iterations to reach the desired state. Hysteresis (jumping between states) would be a problem too, depending on how you tuned it.
                        I suspect the reason the algorithm is designed that way is that it makes it much easier to apply control theory to its design, since the definition does not rely on current state.



                        The CPUFreq governors offer more control. That said, according to this appears that even if CPUFreq specifies a certain frequency, the governor built into the CPU treats it as a suggestion only.
                        Control Theory uses a feedback loop (thus hysteresis), according to the link you provided.

                        Comment


                        • #13
                          Nice, a change (and an article) I can understand .

                          … And I just noticed I don’t have a /sys/devices/system/cpu/cpufreq/ anymore… acpi_cpufreq refuses to load, and /proc/cpuinfo says my Core i3 550 (3.2GHz) is running at 3840.242 MHz. Meh.

                          Comment


                          • #14
                            Originally posted by stqn View Post
                            Nice, a change (and an article) I can understand .

                            … And I just noticed I don’t have a /sys/devices/system/cpu/cpufreq/ anymore… acpi_cpufreq refuses to load, and /proc/cpuinfo says my Core i3 550 (3.2GHz) is running at 3840.242 MHz. Meh.
                            Start the driver manually (i.e.: using modprobe) if you have to. And IIRC, it's

                            Code:
                            acpi-cpufreq
                            , not
                            Code:
                            acpi_cpufreq
                            Last edited by Sonadow; 07-24-2014, 02:21 AM.

                            Comment


                            • #15
                              Originally posted by Sonadow View Post
                              Start the driver manually (i.e.: using modprobe) if you have to. And IIRC, it's

                              Code:
                              acpi-cpufreq
                              , not
                              Code:
                              acpi_cpufreq
                              Thanks Sonadow, I found out today that I had to set EIST to Enabled instead of Auto in my BIOS to make cpufreq work.
                              In module names, - and _ are interchangeable (which is confusing, but true).

                              Comment

                              Working...
                              X