Date:	Mon, 23 Jul 2007 11:19:31 -0700 (PDT)
From:	david@...g.hm
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Igor Stoppa <igor.stoppa@...ia.com>,
	"ext linux-pm-bounces@...ts.linux-foundation.org" 
	<linux-pm-bounces@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-pm <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] Power Management framework proposal

On Mon, 23 Jul 2007, Arjan van de Ven wrote:

> On Sun, 2007-07-22 at 22:25 -0700, david@...g.hm 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists