Announcement

Collapse
No announcement yet.

Linux's "Ondemand" Governor Is No Longer Fit

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

  • #16
    Originally posted by RahulSundaram View Post
    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.
    Hey Rahul, can you clarify something for me... just how often is the CPU -really- idling on (for example) the Fedora default desktop setup? I get the Race To Idle, I just don't see when the system would ever be able to fully IDLE because of all the daemons and everything thats going on in the background. If you've got things like KDE's nepomuk constantly scanning for changed files (or dropbox / google drive doing the same thing on non-KDE systems), or any kind of server running on the system, dont those things keep the system busy 24/7?

    I guess in my head I'm looking at as hundreds of tiny little while(1=1) loops* constantly doing something / checking for something / waiting for something, and therefore always keeping the CPU busy with -something.-

    *I know that the they arent actually while(1=1) loops, I just used that as a reference.

    Comment


    • #17
      Originally posted by Ericg View Post
      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
      Does not appear active on a yorkfield. Looking at the code it seem there are three supported CPUS:

      Code:
      diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
      index cc3a8e6..2300269 100644
      --- a/drivers/cpufreq/intel_pstate.c
      +++ b/drivers/cpufreq/intel_pstate.c
      @@ -600,6 +600,7 @@ static void intel_pstate_timer_func(unsigned long __data)
       static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
       	ICPU(0x2a, default_policy),
       	ICPU(0x2d, default_policy),
      +	ICPU(0x3a, default_policy),
       	{}
       };
       MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
      The 0x3a hex entry corresponds to ivybridge. One of the previous two must be sandy. No idea what the other corresponds to ... perhaps there are two different ids for sandy (desktop and mobile)?

      Comment


      • #18
        The 0x3a hex entry corresponds to ivybridge. One of the previous two must be sandy. No idea what the other corresponds to ... perhaps there are two different ids for sandy (desktop and mobile)?
        Sandy bridge: 0x2A, 0x2D
        Ivy bridge: 0x3A, 0x3E
        Haswell: 0x3c, 0x45

        according to cpu_idle.c

        EDIT:

        case 0x2a: /* Sandy Bridge Core */
        case 0x2d: /* Sandy Bridge Xeon */

        from http://marc.info/?l=openbsd-tech&m=129367135817628
        Last edited by halo9en; 05-18-2013, 03:43 AM.

        Comment


        • #19
          Originally posted by Ericg View Post
          Hey Rahul, can you clarify something for me... just how often is the CPU -really- idling on (for example) the Fedora default desktop setup?
          Well, the default desktop isn't very optimized at this point but is getting better. Refer to https://bugzilla.redhat.com/show_bug.cgi?id=963210. That is a tracker bug primarily for boot speed (and just in case anyone thinks it doesn't matter for servers or what not, refer to point 3 at http://0pointer.de/blog/projects/the-biggest-myths.html) but starting all these services does prevent the system from going idle for the most part. powertop reports can tell you the details.

          If you are running the crawlers (Nepomuk, tracker etc), you are pretty screwed and should stop them unless you have a very real benefit from them on a day to day basis. On servers, deep sleep is very much possible.

          Comment


          • #20
            Originally posted by RahulSundaram View Post
            Well, the default desktop isn't very optimized at this point but is getting better. Refer to https://bugzilla.redhat.com/show_bug.cgi?id=963210. That is a tracker bug primarily for boot speed (and just in case anyone thinks it doesn't matter for servers or what not, refer to point 3 at http://0pointer.de/blog/projects/the-biggest-myths.html) but starting all these services does prevent the system from going idle for the most part. powertop reports can tell you the details.

            If you are running the crawlers (Nepomuk, tracker etc), you are pretty screwed and should stop them unless you have a very real benefit from them on a day to day basis. On servers, deep sleep is very much possible.
            On my SandyBridge Laptop Powertop shows about 90% Idle (Disabled Clock) and 85% C7 sleep states, while writing this on KDE. I don't know if this is good or bad :-D

            Comment


            • #21
              Originally posted by Ericg View Post
              Hey Rahul, can you clarify something for me... just how often is the CPU -really- idling on (for example) the Fedora default desktop setup? I get the Race To Idle, I just don't see when the system would ever be able to fully IDLE because of all the daemons and everything thats going on in the background. If you've got things like KDE's nepomuk constantly scanning for changed files (or dropbox / google drive doing the same thing on non-KDE systems), or any kind of server running on the system, dont those things keep the system busy 24/7?
              No, they listen for file-system changes. Unless you change a file, the file indexer/syncer will not reindex it.

              Comment


              • #22
                Just updated to kernel 3.9 on my Ivy Bridge laptop to see if it makes a difference. It's hard to say non-subjectively without being lazy and doing some real objective testing, which I didn't, but it seems to have made a difference in both battery life, cpu temperatures, and hence fan noise when doing various tasks.

                Comment


                • #23
                  Originally posted by carewolf View Post
                  No, they listen for file-system changes. Unless you change a file, the file indexer/syncer will not reindex it.
                  Correct, there is a kernel API which does that, so userspace can go to sleep and just get notified by the filesystem.

                  Comment


                  • #24
                    Originally posted by molecule-eye View Post
                    Just updated to kernel 3.9 on my Ivy Bridge laptop to see if it makes a difference. It's hard to say non-subjectively without being lazy and doing some real objective testing, which I didn't, but it seems to have made a difference in both battery life, cpu temperatures, and hence fan noise when doing various tasks.
                    What does /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor say for you?
                    I thought that Ivy Bridge is not yet supported?

                    Comment


                    • #25
                      Originally posted by user82 View Post
                      What does /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor say for you?
                      I thought that Ivy Bridge is not yet supported?
                      Look at #17.

                      My mobile ivy bridge:
                      Code:
                       $ cpupower frequency-info
                      analyzing CPU 0:
                        driver: intel_pstate
                        CPUs which run at the same hardware frequency: 0
                        CPUs which need to have their frequency coordinated by software: 0
                        maximum transition latency: 0.97 ms.
                        hardware limits: 1.20 GHz - 3.20 GHz
                        available cpufreq governors: performance, powersave
                        current policy: frequency should be within 1.20 GHz and 3.20 GHz.
                                        The governor "performance" may decide which speed to use
                                        within this range.
                        boost state support:
                          Supported: yes
                          Active: yes
                          25500 MHz max turbo 4 active cores
                          25500 MHz max turbo 3 active cores
                          25500 MHz max turbo 2 active cores
                          25500 MHz max turbo 1 active cores

                      Comment


                      • #26
                        Originally posted by user82 View Post
                        What does /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor say for you?
                        I thought that Ivy Bridge is not yet supported?
                        Only if patched.

                        Comment


                        • #27
                          Originally posted by Ericg View Post
                          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.
                          Do you think that they will actually submit such code with them shutting down their OSRC and laying off their developers responsible for their cpufrq/PowerNow developers?

                          http://www.phoronix.com/scan.php?pag...tem&px=MTIyMDQ

                          Comment


                          • #28
                            Originally posted by deanjo View Post
                            Do you think that they will actually submit such code with them shutting down their OSRC and laying off their developers responsible for their cpufrq/PowerNow developers?

                            http://www.phoronix.com/scan.php?pag...tem&px=MTIyMDQ
                            I don't THINK AMD is gonna be in business within the next 5 years. And while I realize that does not exactly answer your question, in a way it does.

                            Comment


                            • #29
                              Originally posted by Ericg View Post
                              I don't THINK AMD is gonna be in business within the next 5 years. And while I realize that does not exactly answer your question, in a way it does.
                              Not possible. Even though AMD hardware is really unspectacular they beat Intel hands down in the performance-cost ratio. Intel can play the price game, but if they drop their prices to the level of AMD's there will most certainly be some silly lawsuit being filed on the grounds of the most heavily abused word in the industry: anti-competition. (or dumping, whatever).

                              Not to mention AMD has some presence in the dedicated GPU market. Although the alleged performance of Haswell's onboard graphics core are destroying that presence...

                              Comment


                              • #30
                                Originally posted by Sonadow View Post
                                Not possible. Even though AMD hardware is really unspectacular they beat Intel hands down in the performance-cost ratio. Intel can play the price game, but if they drop their prices to the level of AMD's there will most certainly be some silly lawsuit being filed on the grounds of the most heavily abused word in the industry: anti-competition. (or dumping, whatever).

                                Not to mention AMD has some presence in the dedicated GPU market. Although the alleged performance of Haswell's onboard graphics core are destroying that presence...
                                Are they -really- beating Intel on the value end of the spectrum though? Core i5 Haswell is gonna have MORE than adequate graphics for anything up to gaming (and even some gaming) great CPU performance, power consumption is going to be at near-ARM levels, all for about $200 I'm guessing, maybe less. AMD's graphics may be better, but they are still reeling from the clusterfsck known as Bulldozer, their power consumption is up, they cant even idle at the levels that Intel can, and their chips cost between $100 and $200 for Piledriver.

                                Quite honestly, at least for me, I wont even CONSIDER an AMD APU for a Laptop just because of the heat and power consumption. Desktop, okay, maybe they have a shot in one of my builds just because power consumption doesnt matter as much there.

                                Comment

                                Working...
                                X