Re: Power Management framework proposal

On Sun, 2007-07-22 at 11:56 -0700, david@xxxxxxx wrote:

I have a concern with this approach though. It seems to assume that
there is one global thing somewhere that sets the system state; in my
experience that is the wrong approach; in fact there is a very definite
evidence that there are many decisions on power that are to be made
local at a high frequency. An example of this is the processor speed;
the ondemand governer does exactly this for the cpus that can switch
speeds fast; it's just impossible to beat such a local, fast decision
with anything on a global scale.

the intent was not to have one global call that sets the mode on all
devices, but rather have one call for each device/subsystem, just the same
call in each case.

there's also nothing that says that there can only be one thing setting
the mode (although that does mean a fourth call 'report_current_mode()' or
similar is needed). and if you choose to have two pieces of software
managing the same device things could get 'interesting'.

as for the speed that such decisions need to be made.

this API is not saying anything about the speed of the decisions.
it's also not saying anything about if the decision makeing is being done
by kernelspace or userspace. it's just providing a common way for whatever
software is doing the decision makeing to find out it's options and set
the modes.


but it makes for a layer between the device and the setting of the
modes.. which sort of would defeat the option of having things truely
local.

Settings don't mean much in general (in specific cases, maybe), it's the
requirements that matter. The *intent* matters. Linus forced this into
cpufreq way back, and while I and perhaps others thought he was just
being silly, 6 years later it turns out he was absolutely right.

Maybe something else
A power policy management framework doesn't need a unified framework (I
know this for a fact, I'm hoping to release the code within a few
weeks). A unified interface doesn't even help one single bit: the
semantics of each part is *extremely* different even if you make it look
the same; the sameness is only cosmetic.

The consequences of managing a disk vs managing a cpu vs managing the
LCD brightness via the X server are all very different. The tradeoffs
you need to make are all very different. The things you want to control
are all very different. Trying to force a standard interface makes the
interface for a specific subsystem go away from the *actual* best
interface for that subsystem, for no gain since the thing that manages
the policy needs to have different parts for each *anyway*.



Now I realize that the needs for "hard small embedded" are different
from "PC like", and to be honest, I don't think it's entirely possible
to unify them; I don't think it's even worthwhile to pursue that (look
at where those attempts have gotten us so far)... but I suspect even in
the small embedded space a standard, forced and thus unnatural interface
isn't what is needed.


--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Network Speed Question
    ... speeds are either 10 or 100 Mbs. ... The PIX 506 and PIX 506E are identical in supported interface line ... The documentation does indicate that autonegotation is only supported ... with the 6.3allowing it to go to 100 Mbps. ...
    (comp.dcom.lans.ethernet)
  • Re: Network Speed Question
    ... speeds are either 10 or 100 Mbs. ... there is no point in upgrading to a PIX ... The PIX 506 and PIX 506E are identical in supported interface line ... with the 6.3allowing it to go to 100 Mbps. ...
    (comp.dcom.lans.ethernet)
  • Re: Fastest External HDD Interface?
    ... months or so I've been exploring external HDD interfaces. ... don't know how to handle these speeds? ... External SATA will give you just the same speed as an internal ... But note that the SATA interface speed is significantly higher ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: Fastest External HDD Interface?
    ... months or so I've been exploring external HDD interfaces. ... don't know how to handle these speeds? ... External SATA will give you just the same speed as an internal ... But note that the SATA interface speed is significantly higher ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: Sparse files
    ... interface for managing them that I am yet to spot? ... I implemented my own for DiscKnight though, ...
    (comp.sys.acorn.programmer)