PowerPolicyManagement
|
Size: 16007
Comment:
|
Size: 16429
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 24: | Line 24: |
| == Goals == The power policy manager for linux is meant to be a universal, cross-platform framework for reducing power consumption in linux based devices; with particular focus on handhelds. We have three primary design goals. The first is to establish an interface, based on Dbus, that can be used by applications or a GUI to provide usage model information to a power manager daemon. Usage model info is intended to help us understand where, when, how, and for what purpose the device is being used. These attributes can help us intelligently regulate power and performance to match the users neds and expectations. The second goal is to identify what subsystem micro-policy managers are already available for us to manipulate in the PPM daemon; and what, if any, control improvements we can add which will allow the macro-policy to further optimize the micro-policies. The third goal is to identify subsystems which can be optimized for power, but that which have no existing micro-policy scheme. We will work with the linux communitys subsystem maintainers to design and implement a micro-policy scheme that can be intergrated into PPM as a whole. |
== Architecture == The power policy manager for linux is meant to be a universal, cross-platform framework for reducing power consumption in linux based devices; with particular focus on handhelds. It is implemented in three parts: a configuration data layer, a micro policy engine control layer, and a daemon that ties the two together. * '''Configuration Layer''': Provides “configuration element” messages from a GUI, applications, and system agents which describe the optimization potential in the system. e.g. user focus, device position, handling, and movement, and application needs. The Configuration Element Interface (CEI), will be based on Dbus and can be used by applications or a GUI to provide usage model information to our power manager daemon. Usage model info is intended to help us understand where, when, how, and for what purpose the device is being used. These attributes can help us intelligently regulate power and performance to match the users neds and expectations. * '''MPE Layer''': Provides “tunable element” control access to all the subsysems on the platform. e.g. LCD brightness, Audio codec, etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already available to us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for power cleanly. Micro-policy engines will exist for each subsystem we intend to control. * '''PPM Daemon''': Defines what groupings of configuration elements are configuratble from the GUI, and the mappings between configuration and tunable elements. attachment:C__fromlaptop_ppm_small.jpg |
| Line 41: | Line 44: |
| https://umd.jf.intel.com/projects/umd/attachment/wiki/PowerPolicyManagement/ppm_small.jpg |
Overview
Introduction
Power optimization for PC Architecture is vastly different from that for embedded systems such as ARM based PDAs or Cell phones. This is because each embedded chipset has its own unique set of power management features that require a custom flavor of linux built from the ground up. PC based chipsets already have a well established code base in linux, with existing hardware interfaces such as ACPI and HAL; and as they have evolved from desktops into smaller, more portable systems, a wealth of software packages have been created to optimize power.
Each of these packages can be thought of as a power micro-policy controller for a specific subsystem on a linux based platform. For instance cpufreq manages power for the CPU supsystem, or the iwconfig interface manages device specific power for the Network (WLAN) subsystem. Currently all these micro-policy managers function independantly of one another and with little or no information from the user domain. Thus there are two things lacking in linux with regard to power. The first is a centralized policy manager which can gather input from ACPI, the user, and running applications to generate a complete picture of how the device is being used. This information can be used to create macro-policies which can selectively tune or override the systems micro-policy managers to achieve far greater power optimization. The second piece missing is a scheme to create micro-policy managers for all power-hungry subsystems that dont currently support any form of control.BR
- Macro-policy focus is on the usage model
- Where is the user and device (e.g. stationary vs moving, near to vs from from a power source, inside or outside)
- When is the device being used (e.g. night vs day)
- How is the device being used (e.g. is the user listening to it, looking at it, controlling it)
- What is the device being used for (e.g. using network, playing audio, displaying video, high vs low performance)
- Micro-policy focus is on the subsystem and driver level
- Groupings by power optimization capability
- CPU (single or multi-core)
- Network (LAN, WLAN, WWAN)
- Storage (Harddisk, Flashdisk, DVDROM)
- Human Interface Devices (Mouse, Keyboard, Touchscreen)
- Video (LCD, Graphics card)
- Audio (Speakers, Headphones, AC97, HD Audio)
- Wireless Connections (Bluetooth, GPS)
Architecture
The power policy manager for linux is meant to be a universal, cross-platform framework for reducing power consumption in linux based devices; with particular focus on handhelds. It is implemented in three parts: a configuration data layer, a micro policy engine control layer, and a daemon that ties the two together.
Configuration Layer: Provides “configuration element” messages from a GUI, applications, and system agents which describe the optimization potential in the system. e.g. user focus, device position, handling, and movement, and application needs. The Configuration Element Interface (CEI), will be based on Dbus and can be used by applications or a GUI to provide usage model information to our power manager daemon. Usage model info is intended to help us understand where, when, how, and for what purpose the device is being used. These attributes can help us intelligently regulate power and performance to match the users neds and expectations.
MPE Layer: Provides “tunable element” control access to all the subsysems on the platform. e.g. LCD brightness, Audio codec, etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already available to us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for power cleanly. Micro-policy engines will exist for each subsystem we intend to control.
PPM Daemon: Defines what groupings of configuration elements are configuratble from the GUI, and the mappings between configuration and tunable elements.
attachment:Cfromlaptop_ppm_small.jpg
These data points represent very specific conditions which may affect power or performance. Some can be used immediately for obvious purposes, but some are just there as placeholders for some future benefit. The user will likely never provide this information manually at this level. Usage model data at this granularity will be provided by the system (ACPI, HAL, Applications, or the GUI in the form of a macro). Each type of input can be broken down into a set of specific "configuration elements" which are what is actually sent across DBUS.
These refer to how the user will interact with the MID. These represent the only things that the user MUST tell us. Config Element(string) Target(string) Value(string) Value(int) videofocus lcdmon,extmon,exttv none,rare,intermittent,often,constant X ms (reaction time needed) audiofocus speakers,headphones,ext none,rare,intermittent,often,constant X ms (reaction time needed) userinput keypad,mouse,touchscr,camera none,rare,intermittent,often,constant X ms (reaction time needed) tgtbattlife all 1hour,2hour,4hour,8hour,max X minutes til off
These refer to the physical position and state of the MID. They are things that for the most part the user will have to enter, but we can work to make most of these automatically detected. < 20 (e.g. in transit between home and work) < 120 (e.g. general mobile usage) < 240 (e.g. a standard plane ride in coach) < 480 (e.g. a standard college school day) < 30 (e.g. charging at airport lounge, plane leaves soon) < 120 (e.g. charging while at a restaurant) < 480 (e.g. charging the night before) Config Element(string) Target(string) Value(string) Value(int) radios BT,Wifi,Wimax,GPS forceoff,allowon 0, 1 extpower outlet,battery ac,car,plane,solar,extbatt X mw (total charge capacity) ETA (Estimated Time of Arrival) outlet,celltower,wifihotspot 1hour,2hour,4hour,8hour,max X minutes to target ETD (Estimated Time of Departure) outlet,celltower,wifihotspot 1hour,2hour,4hour,8hour,max X minutes at target ambientlight all midnight,candlelight,officelight,daylight,sunlight X % of direct sunlight movement all still,walk,jog,bike,car,train,plane X meters per minute
These are just examples of what the PPM can do if it knows the date and time. The input here is just the system clock. Config Element(string) Target(string) Value(string) Value(int) DATE all local date - TIME all local time -
These refer to what the MID and its devices are being used for. All of this should come from device input rather than from the user (i.e. from the application itself). Config Element(string) Target(string) Value(string) Value(int) cpu CPU0,CPU1,... off,low,med,hi,max X % of max perf needed appfocus pid (process id) none,rare,intermittent,often,constant X % of full user attention network LAN,WLAN,WWAN none,rare,intermittent,often,constant X kbps of bandwidth acpi outlet,battery,keypad,mouse,touchscreen,radios enabled,disabled 1,0
These are high level usage models that the user can actually provide. They are just combinations of usage model data points that can be deduced from the high level picture. These could be input from the GUI.
These are examples of what the GUI could allow the user to choose so that the PPM can determine the User's Focus and (at least until we get this from the device) the Device position. Proximity to power source = < 120 minutes to power Proximity to power source = < 120 minutes to power Proximity to power source = Plugged in or < 20 minutes to power Proximity to power source = Plugged in or < 480 minutes to power
These are just examples of certain application workloads that could be running on the system which can tell the PPM what the device is being used for. We could actually provide these groupings as inputs in their own right or force apps to just provide low level data points.
Constraints
Configuration Input Layer
List of Configuration Elements
User Focus
Device Position
Time of Use (System Clock)
Application
High Level Usage Models
Input from GUI
Input from Device
Subsystems We Can Optimize For Power
CPU
Audio
Video
Network
Human Interface Devices
Storage
Examples of how PPM can help save power
Design
Overview
Interfaces
MobileAndEmbedded/PowerPolicyManagement (last edited 2008-08-06 16:26:39 by localhost)