linux-kernel - Re: [linux-pm] Power Management framework proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0707222207210.6350@asgard.lang.hm>
Date:	Sun, 22 Jul 2007 22:25:57 -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 Sun, 22 Jul 2007, Arjan van de Ven wrote:

> On Sun, 2007-07-22 at 21:04 -0700, david@...g.hm wrote:
>
>>>> this strategy should work well on the normal unpredictable workload that
>>>> most people deal with, but there are some cases where the workload becomes
>>>> pretty predictable (media players for example) where there really is less
>>>> variation, and a need for a constant availability of the cpu, so it may
>>>> actually save a smidge of power to run below the highest freq that the
>>>> voltage allows rather then running faster and being idle more cycles.
>>>
>>> that actually is the example showcase of race-to-idle where you
>>> absolutely want to run at the highest frequency..
>>
>> 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?

>> and the
>> computation capacity per watt of power is the same at all frequencies. the
>> chip performance numbers I've been seeing (which I admit are mostly
>> embedded datasheets) indicate that neither of these hold true.
>
> let me give you a real world example then, and the numbers I'm using are
> ballpark the same as you'll find in a (mobile) core 2 duo datasheet, I
> just rounded them a little so that the math works out nice.
>
> power at full speed: 34W
> power at half speed: 24W
> power at idle: 1W

are these numbers for the CPU itself or for the a larger chunk? I could 
easily see these numbers for motherboard (including CPU and RAM), but it 
would surprise me if these numbers are for the CPU itself. I'm used to 
seeing datasheets that have a much more linear voltage/freq (and therefor 
a quadratic voltage/power) curve. in some cases the voltage requirements 
drop faster then the frequency.

> assume media playback, and a dumb one, that takes half a second to
> decode a second of media. (again to make the math simple)
>
> at half speed: Energy for a second is 0.5 * 24 + 0.5 * 1 = 12.5 J
> at full speed: Energy for a second is 0.25 * 34 + 0.75 * 1 = 9.25 J
>
> 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. 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.

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

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/