On Mon, 23 Jul 2007, Arjan van de Ven wrote:
On Sun, 2007-07-22 at 22:25 -0700, david@xxxxxxx wrote:
only if the transitions don't cost anything significant,
these are second order effects though. On a pc, the transition costs are
quite low (as I said, single or low double digit microseconds).
including pausing all drivers before the transition and unpausing them
aftrwords?
on a PC you don't need to do that.
that's not what the OWAP documentation I was told to read said. it
specificly lists a requirement to pause drivers before the clock change
and unpause them afterwords.
this works for all systems where the idle power is more lower than the
power you save by dropping speed... and that is almost all of them in
the PC world.
if you can idle the system as a whole I agree with you fully. most PC
hardware (including the mobile stuff) doesn't change it's power
consumption much with load.
even if the rest of the PC is unchanging (which it's not), it is just an
offset to both sides of the equation, and the same on both sides at
that.
but a constant added to both sides makes the relative savings less.
at Usenix there was a presentiation (I don't
remember if it was by Amazon or Google) about this subject, showing that
current PC hardware only goes down to 50% power when idle (short of
switching power modes) and that they and other big companies were pushing
vendors to improve their hardware, aiming to get the idle power down to
10% (again without suspending anything). so there's some chance that this
will change before too long.
on servers and such, there is a huge offset, sure, but still the effect
is there. And it really isn't 50%.
their measurements and graphs say otherwise.
now you can argue that 0.5 seconds is a really really long time, and
you'd be right. so for really really short stints (say a timer
interrupt) you don't want to change the voltage at all (nor would
you
want to change the plls to change frequency for that matter). But
once
you start chaning those, you might as well go full speed.
this assumes that you can cache 1 second of video, if you have more
real-time requirements you have a much harder time (say video
confrancing
where you don't get the frame until just before you need to display
it)
the same basic math holds for just 1 frame at a fixed rate. At some
point transition costs will get you (and that's where things like
ondemand delayed speedup will save us); but to get back to your
interface, the interface doesnt nearly give the info needed to make
these decisions...
what is it missing?
it lets you find out what modes are avialable and (in relative terms) how
much capability and power is available in each mode
it lets you find out what the transition costs are from any mode to any
other mode
David Lang
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
