cpufreqd as standard install?

Matthew Garrett mjg59 at srcf.ucam.org
Thu Mar 8 22:35:11 UTC 2012

On Thu, Mar 08, 2012 at 05:29:47PM -0500, Phillip Susi wrote:

> You also need to remember that 3.4x the clock speed does not mean you 
> actually end up finishing your work 3.4x faster.  Intel recommends 
> using the ondemand governor, so if you are claiming they are wrong, 
> and you save more power using performance, that's going to take a 
> little convincing.  I checked on my desktop sandybridge core i5 
> system, and I found that running stress -c 4 with powersave draws 150 
> watts, and with ondemand, is nearly 200 watts.  Idle, the system draws 
> 125 watts.  Factoring out that baseline gives a cpu load of 25 vs 75 
> watts depending on whether you run at 1600 MHz vs 3300 MHz, or 3x the 
> power for twice the speed.

Do a SpecPOWER run with performance and with ondemand and you'll see 
that there's very little difference on modern hardware.

> > But this is a very strange workload to be optimising for. First, it's 
> > entirely CPU-bound. If it involves IO then you're going to be keeping IO 
> > devices in a higher power state for longer, which wipes out the 
> > advantage. Second, it makes the assumption that the user doesn't care 
> > how much time it takes. That's basically never true.
> We're not talking about a 100% cpu bound workload of course; we're 
> talking about typical loads where the cpu is mostly idle, and the 
> question is whether it is better to spend a bit more time idle, and be 
> less efficient when actually executing instructions, or be more 
> efficient at the cost of a little less idle time.  If you ignore the 
> time it takes to enter/exit the deep C states, you can model the 
> different execution speeds and how much energy they consume as a 
> simple 100% busy period followed by a fully idle period, with a total 
> duration being the same in both tests.

You're ignoring far too many factors for this to be terribly relevant.

Matthew Garrett | mjg59 at srcf.ucam.org

More information about the Ubuntu-devel-discuss mailing list