Announcement

Collapse
No announcement yet.

Linux's "Ondemand" Governor Is No Longer Fit

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

  • #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


            • #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

                      Working...
                      X