[lkml]   [2007]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] Power Management framework proposal
    On Sun, 2007-07-22 at 22:25 -0700, 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.

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

    the cpu at full load.

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

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

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

    if you want to mail me at work (you don't), use arjan (at)
    Test the interaction between Linux and your BIOS via

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-23 16:17    [W:0.024 / U:7.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site