Re: Power Management framework proposal
On Sun, Jul 29, 2007 at 03:00:07PM -0700, [EMAIL PROTECTED] wrote: > yes it is, and each type of device is growing it's own, incompatible, > interfaces for controlling things like this. I was aiming to do two > things. Anything playing with power management needs to be aware of the limitations of the hardware. Many devices have reduced functionality when in reduced power states, and it's vital that the caller be aware of that. There's no way to express that information in a consistent way because the limitations vary widely between different types of device. So, given that software will need to be aware of the different special cases for different types of hardware, there's very little cost to each of them exposing a different interface. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Fri, 27 Jul 2007, Pavel Machek wrote: Hi! example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. that's what the description is for. this info can be provided by the driver as part of the list_modes() function. That's what /sys/class/backlight/ is for :-). yes it is, and each type of device is growing it's own, incompatible, interfaces for controlling things like this. I was aiming to do two things. 1. head this off and try and get a more common api 2. simplify the confusion that there is with multiple functions needing to be implemented during the suspend/resume cycle by chaning them from independant suspend-only functions to being just part of the device settings as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. assuming that nobody else chimes in to disagree with you I'll accept your judgement and drop the issue. Just for the record, I agree with Arjan here. oh well. sorry to take up everyone's time. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Fri, 27 Jul 2007, Pavel Machek wrote: Hi! example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. that's what the description is for. this info can be provided by the driver as part of the list_modes() function. That's what /sys/class/backlight/ is for :-). yes it is, and each type of device is growing it's own, incompatible, interfaces for controlling things like this. I was aiming to do two things. 1. head this off and try and get a more common api 2. simplify the confusion that there is with multiple functions needing to be implemented during the suspend/resume cycle by chaning them from independant suspend-only functions to being just part of the device settings as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. assuming that nobody else chimes in to disagree with you I'll accept your judgement and drop the issue. Just for the record, I agree with Arjan here. oh well. sorry to take up everyone's time. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, Jul 29, 2007 at 03:00:07PM -0700, [EMAIL PROTECTED] wrote: yes it is, and each type of device is growing it's own, incompatible, interfaces for controlling things like this. I was aiming to do two things. Anything playing with power management needs to be aware of the limitations of the hardware. Many devices have reduced functionality when in reduced power states, and it's vital that the caller be aware of that. There's no way to express that information in a consistent way because the limitations vary widely between different types of device. So, given that software will need to be aware of the different special cases for different types of hardware, there's very little cost to each of them exposing a different interface. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
Hi! > >>example 1: a laptop screen > >> > >>mode capacity power description > >>000off > >>1 100 100full brightness > >>2 70 60half power to the backlight > >>3 50 35quarter power to the backlight > >>4 30 25eighth power to the backlight > >>55 10backlight off. > >> > >>example 2: a front-panel display on a server (no > >>variable backlight > >>control) > >> > >>mode capacity power description > >>0 00 off > >>1 100 100 backlight on > >>2 50 10 backlight off > > > > > >the problem is: the person who SETS these needs to know > >what they mean. > > that's what the description is for. this info can be > provided by the driver as part of the list_modes() > function. That's what /sys/class/backlight/ is for :-). > >as someone who wrote (part of) a power policy manager; > >sorry but you > >take away information I need, and in addition the > >different API's are > >absolutely no big deal. > > assuming that nobody else chimes in to disagree with you > I'll accept your judgement and drop the issue. Just for the record, I agree with Arjan here. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
Hi! example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. that's what the description is for. this info can be provided by the driver as part of the list_modes() function. That's what /sys/class/backlight/ is for :-). as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. assuming that nobody else chimes in to disagree with you I'll accept your judgement and drop the issue. Just for the record, I agree with Arjan here. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Tue, 2007-07-24 at 16:02 -0700, [EMAIL PROTECTED] wrote: > > what requirements are needed? (I'm sure that there are others, but > hopefully it's possible to avoid requirements like 'the clock speed > for > device A must be >X to allow device B to operate in mode Y') I had an idea a while ago, might still be in the pm list archives, of exposing constraints as opaque bitmaps. The bits have defined meaning for a given bus, but are opaque to the core. The devices however, provide tables indicating to the core their list of power states (with names) and their requirements in term of parent states (using such bitmasks). Thus, the core can resolve the dependency requirements without having to know about the actual meaning of the states of the various busses. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Wed, 25 Jul 2007, Benjamin Herrenschmidt wrote: On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote: I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. what sort of contraints are you thinking of? A parent power state defines what states children can be in. For example. A way to express those dependencies would be nice. Or alternatiely, the power state of all the children defines the power state a parent can go in automatically. Ok, I see tow things here. 1. do you really want to try and propogate things like this from one to the other, or would it be good enough to flag the issue and let the software selecting the modes implement this contraint? 2. how can you standardize the requirements? at the very least you have for this mode all children must be off for this mode all children must be in a mode that includes a 'suspended' flag (this could be made implicit by saying that you must suspend children before parents) and then just flagging the 'suspended, but not off' modes) what requirements are needed? (I'm sure that there are others, but hopefully it's possible to avoid requirements like 'the clock speed for device A must be >X to allow device B to operate in mode Y') David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote: > > I think we need a set of constraints that trickle down the power > tree > > and limit what a given driver can do locally. > > what sort of contraints are you thinking of? A parent power state defines what states children can be in. For example. A way to express those dependencies would be nice. Or alternatiely, the power state of all the children defines the power state a parent can go in automatically. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Tue, 24 Jul 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-07-22 at 10:26 -0700, Arjan van de Ven wrote: On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] 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. On the other hand, some things (the high level goals and constraints) are obviously global. I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. what sort of contraints are you thinking of? David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Tue, 24 Jul 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-07-22 at 10:26 -0700, Arjan van de Ven wrote: On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] 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. On the other hand, some things (the high level goals and constraints) are obviously global. I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. what sort of contraints are you thinking of? David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote: I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. what sort of contraints are you thinking of? A parent power state defines what states children can be in. For example. A way to express those dependencies would be nice. Or alternatiely, the power state of all the children defines the power state a parent can go in automatically. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Wed, 25 Jul 2007, Benjamin Herrenschmidt wrote: On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote: I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. what sort of contraints are you thinking of? A parent power state defines what states children can be in. For example. A way to express those dependencies would be nice. Or alternatiely, the power state of all the children defines the power state a parent can go in automatically. Ok, I see tow things here. 1. do you really want to try and propogate things like this from one to the other, or would it be good enough to flag the issue and let the software selecting the modes implement this contraint? 2. how can you standardize the requirements? at the very least you have for this mode all children must be off for this mode all children must be in a mode that includes a 'suspended' flag (this could be made implicit by saying that you must suspend children before parents) and then just flagging the 'suspended, but not off' modes) what requirements are needed? (I'm sure that there are others, but hopefully it's possible to avoid requirements like 'the clock speed for device A must be X to allow device B to operate in mode Y') David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Tue, 2007-07-24 at 16:02 -0700, [EMAIL PROTECTED] wrote: what requirements are needed? (I'm sure that there are others, but hopefully it's possible to avoid requirements like 'the clock speed for device A must be X to allow device B to operate in mode Y') I had an idea a while ago, might still be in the pm list archives, of exposing constraints as opaque bitmaps. The bits have defined meaning for a given bus, but are opaque to the core. The devices however, provide tables indicating to the core their list of power states (with names) and their requirements in term of parent states (using such bitmasks). Thus, the core can resolve the dependency requirements without having to know about the actual meaning of the states of the various busses. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 2007-07-22 at 10:26 -0700, Arjan van de Ven wrote: > On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] 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. > > On the other hand, some things (the high level goals and constraints) > are obviously global. I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 2007-07-22 at 10:26 -0700, Arjan van de Ven wrote: On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] 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. On the other hand, some things (the high level goals and constraints) are obviously global. I think we need a set of constraints that trickle down the power tree and limit what a given driver can do locally. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 22 Jul 2007, Arjan van de Ven wrote: Date: Sun, 22 Jul 2007 21:00:39 -0700 From: Arjan van de Ven <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: LKML , linux-pm <[EMAIL PROTECTED]> Subject: Re: Power Management framework proposal example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. that's what the description is for. this info can be provided by the driver as part of the list_modes() function. And the side that implements these needs to translate them as well... that's two translations, and information is lost in the abstract number in the middle that doesn't mean anything with the current implementations you instead need to know what function to call and what the meaning of that function is. that's not documented in any system discoverable way, you have to read the driver documentation or code to find it. if you don't want to make the shift with cpufreq, that's fine. it sounds like you are at least 90% of the way there anyway, it's not that big a deal, but do you think that there's value in replacing the current ad-hoc approach with something more structured (even if it's not this proposal)? as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. assuming that nobody else chimes in to disagree with you I'll accept your judgement and drop the issue. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
> example 1: a laptop screen > > mode capacity power description > 000off > 1 100 100full brightness > 2 70 60half power to the backlight > 3 50 35quarter power to the backlight > 4 30 25eighth power to the backlight > 55 10backlight off. > > example 2: a front-panel display on a server (no variable backlight > control) > > mode capacity power description > 0 00 off > 1 100 100 backlight on > 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. And the side that implements these needs to translate them as well... that's two translations, and information is lost in the abstract number in the middle that doesn't mean anything > if you don't want to make the shift with cpufreq, that's fine. it > sounds > like you are at least 90% of the way there anyway, it's not that big > a > deal, but do you think that there's value in replacing the current > ad-hoc > approach with something more structured (even if it's not this > proposal)? as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 22 Jul 2007, Arjan van de Ven wrote: On Sun, 2007-07-22 at 11:56 -0700, [EMAIL PROTECTED] 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. and the more I am seeing of cpufreq the more it looks like what I'm proposing, so I'm glad to see that it's a good model :-) 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*. Ok, I can see that if things really are different then it's worth doing different things to control them. however, let me go back to my original post on the subject here right now drivers are supposed to have (forgive me if I get the function names wrong) initialize() shutdown() suspend() suspend_late() resume() resume_early() with suspend taking one of several parameters PM_EVENT_SUSPEND PM_EVENT_FREEZE PM_EVENT_PRETHAW and the notes say that what is supposed to happen is fairly undefined becouse different things can have vastly different capabilities. so to really control the device you need other, per driver interfaces as well. this API is driven by the activities that the suspend process is currently designed to use, and each routine assumes given existing state, if you call it when in any other state the results are undefined. any match to the actual capabilities of the hardware is purely coincidental. to have any ability to control the mode of anything at runtime requires that the code doing so must have specific knowledge of the driver in question. compare this underdefined mess to the sanity that cpufreq gives you for controlling different vendors CPUs with their different capabilities. with cpufreq you somewhere have a table that goes something along the lines of freq voltage 2.0GHz 3.0v 1.5GHz 3.0v 1.0GHz 1.5v 500MHz 0.8v and a function that lets you select the freq you want if cpufreq were to switch over the the API I'm suggesting the table would change to mode capacity power 0 00 1100 100 2 75 100 (or possibly 95, there is some benifit to a slower clock at the same voltage) 3 50 25 4 257 so it would be a relativly minor change, probably causing more disruption then benifit to change in and of itself. also, other then efficiancy arguments, there's nothing that says the modes must be integers not strings. instead of 0-4 above you could use the entries from under freq in the first table. I don't know how cpufreq handles a cpu with logic blocks that can be turned off individually but with the type of API I'm talking about you could easily have
Re: Power Management framework proposal
On Sun, 2007-07-22 at 11:56 -0700, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] 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. 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] 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. 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 2007-07-22 at 11:56 -0700, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 22 Jul 2007, Arjan van de Ven wrote: On Sun, 2007-07-22 at 11:56 -0700, [EMAIL PROTECTED] 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. and the more I am seeing of cpufreq the more it looks like what I'm proposing, so I'm glad to see that it's a good model :-) 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*. Ok, I can see that if things really are different then it's worth doing different things to control them. however, let me go back to my original post on the subject here right now drivers are supposed to have (forgive me if I get the function names wrong) initialize() shutdown() suspend() suspend_late() resume() resume_early() with suspend taking one of several parameters PM_EVENT_SUSPEND PM_EVENT_FREEZE PM_EVENT_PRETHAW and the notes say that what is supposed to happen is fairly undefined becouse different things can have vastly different capabilities. so to really control the device you need other, per driver interfaces as well. this API is driven by the activities that the suspend process is currently designed to use, and each routine assumes given existing state, if you call it when in any other state the results are undefined. any match to the actual capabilities of the hardware is purely coincidental. to have any ability to control the mode of anything at runtime requires that the code doing so must have specific knowledge of the driver in question. compare this underdefined mess to the sanity that cpufreq gives you for controlling different vendors CPUs with their different capabilities. with cpufreq you somewhere have a table that goes something along the lines of freq voltage 2.0GHz 3.0v 1.5GHz 3.0v 1.0GHz 1.5v 500MHz 0.8v and a function that lets you select the freq you want if cpufreq were to switch over the the API I'm suggesting the table would change to mode capacity power 0 00 1100 100 2 75 100 (or possibly 95, there is some benifit to a slower clock at the same voltage) 3 50 25 4 257 so it would be a relativly minor change, probably causing more disruption then benifit to change in and of itself. also, other then efficiancy arguments, there's nothing that says the modes must be integers not strings. instead of 0-4 above you could use the entries from under freq in the first table. I don't know how cpufreq handles a cpu with logic blocks that can be turned off individually but with the type of API I'm talking about you could easily have
Re: Power Management framework proposal
example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. And the side that implements these needs to translate them as well... that's two translations, and information is lost in the abstract number in the middle that doesn't mean anything if you don't want to make the shift with cpufreq, that's fine. it sounds like you are at least 90% of the way there anyway, it's not that big a deal, but do you think that there's value in replacing the current ad-hoc approach with something more structured (even if it's not this proposal)? as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Sun, 22 Jul 2007, Arjan van de Ven wrote: Date: Sun, 22 Jul 2007 21:00:39 -0700 From: Arjan van de Ven [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: LKML linux-kernel@vger.kernel.org, linux-pm [EMAIL PROTECTED] Subject: Re: Power Management framework proposal example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. that's what the description is for. this info can be provided by the driver as part of the list_modes() function. And the side that implements these needs to translate them as well... that's two translations, and information is lost in the abstract number in the middle that doesn't mean anything with the current implementations you instead need to know what function to call and what the meaning of that function is. that's not documented in any system discoverable way, you have to read the driver documentation or code to find it. if you don't want to make the shift with cpufreq, that's fine. it sounds like you are at least 90% of the way there anyway, it's not that big a deal, but do you think that there's value in replacing the current ad-hoc approach with something more structured (even if it's not this proposal)? as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. assuming that nobody else chimes in to disagree with you I'll accept your judgement and drop the issue. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
