cpufreqd as standard install?

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2012 12:11 PM, Matthew Garrett wrote:
> My i7 draws about 7W when fully loaded at 800MHz, and about 27W when 
> fully loaded at 2.7GHz. That's a 3.4x performance improvement at a 
> 3.9x power increase. So, naively, that does result in a fixed amount 
> of work being carried out in a smaller amount of energy, although not 
> anywhere near the extent that you're describing.

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.

I would expect the difference to be less marked on a laptop, since they tend to already have the higher frequencies disabled, keeping the whole range lower down on the exponential power vs performance curve, which would explain your results.  On desktop systems with turbo boost enabled, you're going to climb pretty high up that exponential curve using the max frequency.

I may have stumbled onto a bug because whenever I set the frequency to anything other than the lowest, the highest is used anyway.  cpuinfo_cur_freq reports 3301 MHz even though scaling_cur_freq and scaling_setspeed report the requested lower value.  I would expect the 3000 MHz setting to be a good bit more energy efficient while only giving up a negligible amount of real world performance, but I can't seem to get it to work, so I can't test.

> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPWTLXAAoJEJrBOlT6nu75MWgH/iNkEmgvb3TK7iLxlcaz4zQg
a+BbS2Cu9B4p3OORtG9k5RDTK5k9N5iLOTb1kvchRTJCw8t7XUmTeMzNCrL85JvV
qWSoiEpqGqh1T3lKan2/79Uz3eADoqeY2pRVHHFoxgHjaWT4KXLl8ATozKpvfvJ5
/jYHLH6GbPyIW0IPFXVM329INGnsC0eOqZ43+EHKaWZ8c2kT8e9eXjGydBevvyhd
flyk/R8fj5Iz/AtCIGYrY91/Hwp7A07WKjv81Elfb6BVpebLZjLTomsepKOfGt0T
rayg/YRVjpO3OrO9kbkVbvQjCT9ZKbcG5MtE+6tv63qfajP7F0z2BlT+umBJ4L0=
=QSGz
-----END PGP SIGNATURE-----