Re: Power Management framework proposal
- From: david@xxxxxxx
- Date: Sun, 22 Jul 2007 11:56:04 -0700 (PDT)
On Sun, 22 Jul 2007, Arjan van de Ven wrote:
this approach would allow the transition of ALL drivers to the new mode of
operation in one fell swoop, and then adding additional power management
features is just adding to the existing list rather then implementing new
functions.
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.
one way to represent this in sysfs (as a possible userspace API) would be
power/mode (read to see what mode the device is in, write to set the mode)
power/modelist
power/switching_delay (outputs the delay matrix showing the cost of switching from mode to mode)
although I'm not sure how you would allow the system to report an error this way.
if you have the ondemand governer running, it uses these API's to make it's changes, but if you didn't want to run the ondemand governer you could just do course speed settings through sysfs.
On the other hand, some things (the high level goals and constraints)
are obviously global.
However, your design seems to want to put the low level settings in a
global thing, and that is just a mistake.
I'm proposing a single function name per device, not a single function for the entire system.
David Lang
-
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/
- Follow-Ups:
- Re: Power Management framework proposal
- From: Arjan van de Ven
- Re: Power Management framework proposal
- References:
- Power Management framework proposal
- From: david
- Re: Power Management framework proposal
- From: Arjan van de Ven
- Power Management framework proposal
- Prev by Date: Re: diffutils: C labels misdetected as functions
- Next by Date: Re: [RFH] Partition table recovery
- Previous by thread: Re: Power Management framework proposal
- Next by thread: Re: Power Management framework proposal
- Index(es):
Relevant Pages
|
