Announcement

Collapse
No announcement yet.

Linux's "Ondemand" Governor Is No Longer Fit

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

  • Linux's "Ondemand" Governor Is No Longer Fit

    Phoronix: Linux's "Ondemand" Governor Is No Longer Fit

    By default the Linux kernel uses the "ondemand" CPU frequency governor for achieving maximum clock frequency when system load is high and a lower clock frequency when the system is idle. However, it turns out that for at least modern Intel CPUs, this is likely no longer the case. This default kernel choice may lead to poor battery life and performance for modern Linux systems...

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

  • #2
    I definitely have much longer battery life using onDemand than Performance on my AMD laptop, is this some weird Intel issue?

    Comment


    • #3
      Originally posted by peppercats View Post
      I definitely have much longer battery life using onDemand than Performance on my AMD laptop, is this some weird Intel issue?
      No, OnDemand is still fine for AMD because its AMD. But this is about creating a driver that ACTUALLY does a good job (not a half--assed) job of managing the CPU in terms of power management / performance. Once AMD writes a new scaling driver, like Intel did for intel_pstate, you should switch to that.

      TL;DR: OnDemand is a half assed solution, new pstate drivers are the right solution. Intel only so far. AMD has to write their own.

      Comment


      • #4
        Originally posted by peppercats View Post
        I definitely have much longer battery life using onDemand than Performance on my AMD laptop, is this some weird Intel issue?
        Contrary to some other responses in this thread, yes, that would be some weird intel fuckup. Performance governor basically does this; it sets everything to full speed all of the time. Even having to wake up once in a while will use less power than staying on maximum all of the time. That is, unless you do something REALLY stupid in your CPU design to make it operate like a fluorescent light and suck down more power during startup phase.

        Comment


        • #5
          Originally posted by droidhacker View Post
          Contrary to some other responses in this thread, yes, that would be some weird intel fuckup. Performance governor basically does this; it sets everything to full speed all of the time. Even having to wake up once in a while will use less power than staying on maximum all of the time. That is, unless you do something REALLY stupid in your CPU design to make it operate like a fluorescent light and suck down more power during startup phase.
          Performance doesn't prevent it from going to idle, it can still idle its just at max freqs when not idling.

          Comment


          • #6
            It's especially complicated these days since the CPU and GPU both share the same thermal headroom. Sometimes maxing out the CPU limits the GPU or vice-versa. I'm not really sure what the best solution is, but I'm glad people are looking into it. There are probably some decent gains to be had.
            Free Software Developer .:. Mesa and Xorg
            Opinions expressed in these forum posts are my own.

            Comment


            • #7
              Originally posted by droidhacker View Post
              Contrary to some other responses in this thread, yes, that would be some weird intel fuckup. Performance governor basically does this; it sets everything to full speed all of the time. Even having to wake up once in a while will use less power than staying on maximum all of the time. That is, unless you do something REALLY stupid in your CPU design to make it operate like a fluorescent light and suck down more power during startup phase.
              It has been true for a while that Intel and also Qualcomm CPUs have huge power saving when idle. They can almost power down everything in a core. It is not because Intel has "fucked up." Ondemand simply keeps the CPU from going idle as long as performance governor due to the constant checks that Ondemand does. In other words, letting the CPU idle as soon as and as long as possible gives better power efficiency than keeping the CPU up but at a lower frequency. You could tune Ondemand to keep the CPU idle longer but it would have a detrimental effect on performance.

              Modern CPUs are being built around the idea that you get a job done as fast as possible so you can spend as long as possible in an idle state. This strategy is becoming increasingly important as we keep adding additional cores to CPUs.

              Comment


              • #8
                Originally posted by Kayden View Post
                It's especially complicated these days since the CPU and GPU both share the same thermal headroom. Sometimes maxing out the CPU limits the GPU or vice-versa. I'm not really sure what the best solution is, but I'm glad people are looking into it. There are probably some decent gains to be had.

                That came up during the rc6 development. rc6 bumped the GPU performance because the CPU could go lower thus using less heat and the GPU could then go higher using more heat because the CPU was using less.

                Comment


                • #9
                  Interesting. In pre-3.9, is it sensible to use performance instead of ondemand, or do the benefits only appear on the bleeding edge kernels?

                  Originally posted by Ericg View Post
                  Performance doesn't prevent it from going to idle, it can still idle its just at max freqs when not idling.
                  Yeap. And ondemand also prevents it from going into deeper idle states.

                  Comment


                  • #10
                    Originally posted by Kayden View Post
                    It's especially complicated these days since the CPU and GPU both share the same thermal headroom. Sometimes maxing out the CPU limits the GPU or vice-versa. I'm not really sure what the best solution is, but I'm glad people are looking into it. There are probably some decent gains to be had.
                    *this*

                    Cpufreq is like HAL. We need something like udev. We wake up periodically to poll for the load.This is wrong.
                    Instead, CPU should wake up itself when there is load AND the system should be able to inform CPU (driver) that there is load, so it stays in highest power state as needed.

                    So basically, the system looks if CPU is a "team-player".
                    If it can manage itself, the system (via driver) only limits it to certain lowest possible powerstate, depending on load; if there is no limit, CPU can clock down or up as it sees fit by itself.
                    If its not a "team-player", t.m. it needs to be managed, the driver sets policy manually, that means polling - but still the system can send signal limits to driver telling it, if it can clock down or not. That will resolve the case where the driver clocks down during GPU load and starts bottlenecking the operations.

                    This way it would be possible to resolve your issues, dear Intel; and that of Gallium MESA - see - that is already confirmed issue.
                    Last edited by brosis; 05-17-2013, 04:26 PM.

                    Comment


                    • #11
                      Core 2 Duo

                      What about Core 2 Duo?
                      Could it benefit from this too?
                      Does Core 2 Duo have P-states?
                      Are they working on it or this only for Sandy Bridge and Ivy Bridge?

                      Comment


                      • #12
                        cpufreq-info or common frequency monitors not correctly indicate the frequency used in modern intel processors when using the turbo frequency. A Phoronix user had recommended me in another thread try i7z:
                        https://code.google.com/p/i7z/

                        What is the frequency used in "performance" governor? The frequency is maintained at the normal maximum clock frequency, or turbo frequency?

                        Comment


                        • #13
                          Originally posted by uid313 View Post
                          What about Core 2 Duo?
                          Could it benefit from this too?
                          Does Core 2 Duo have P-states?
                          Are they working on it or this only for Sandy Bridge and Ivy Bridge?
                          Unless one of the Devs says otherwise, I think its Sandy Bridge and up only. Thats what I was getting at from the Google+ post I originally linked to Michael

                          Comment


                          • #14
                            On an Ivy-Bridge CPU qith p-state I could clearly see power savings.
                            Great that Phoronix informed about this!

                            Comment


                            • #15
                              Originally posted by Ericg View Post
                              Performance doesn't prevent it from going to idle, it can still idle its just at max freqs when not idling.
                              To expand on that, instead of throttling the CPU to save power, one can let it run with the maximum speed available and therefore finish it quicker and go to idle sleep sooner. It is not always better to do the latter which is why it is a more tricky thing to tune but is not a Intel specific trade off.

                              Comment

                              Working...
                              X