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