Patrick Bellasi, profile picture
Uploaded byPatrick Bellasi
581 views

Constrained Power Management

The document discusses a proposal for enhanced power management techniques in Linux, highlighting the limitations of current approaches and suggesting a holistic framework for system-wide optimization. It emphasizes the need for a coordinated strategy that integrates multiple subsystem policies while addressing the dependencies between devices and their power management requirements. The proposal aims to improve resource allocation and performance through a combination of local and global optimization strategies, utilizing a formalized model for better power control.

Embed presentation

Downloaded 26 times
Introduction Motivations Proposal Conclusions Constrained Power Management an holistic approach to power management Patrick Bellasi PhD Student Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy ELC-E - October, 15-16 2009
Introduction Motivations Proposal Conclusions Focusing the presentation’s topic Outline • Highlight some issues of current Linux kernel PM support • Advance a proposal to tackle these problems ◦ not a finale solution ◦ try to focus attention on the topic ◦ trigger a discussion to improve this kind of support
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct applications input • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s LCD ACodec WiFi specific dependencies ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct applications input PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct applications input PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system Multiple disjoint policies
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system Multiple disjoint policies How can we achieve system-wide optimization?
Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Multiple-Policy Approach: Potential Issues • Multiple decision points ◦ difficult inter-dependencies tracking ◦ risk of conflicting decisions • Only indirect info about applications QoS requirements ◦ user-space know the requirements, kernel should support them ◦ application requirements should drive kernel frameworks tuning • No proper aggregation on applications requirements ◦ only some frameworks provide it (e.g V/I fw, “new” clock fw) ◦ risk of code duplication • No feed-back on resources availability ◦ applications could require resources from multiple devices ◦ behavior depends on effective availability of all the required resources The composition of almost independent optimization policies cannot grant a system-wide optimization
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction ◦ fine-details, low-overhead • coordination entity ◦ exploit system-wide view ◦ track resource availability and devices’ inter-dependencies • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements ◦ feedback on resource availability Distributed control model • constraint assertion QoS requirements set constraint on local policies
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction ◦ fine-details, low-overhead • coordination entity ◦ exploit system-wide view ◦ track resource availability and Coordination Entity devices’ inter-dependencies resource availability inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements ◦ feedback on resource availability Distributed control model • constraint assertion QoS requirements set constraint on local policies
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction ◦ fine-details, low-overhead • coordination entity ◦ exploit system-wide view Global ◦ track resource availability and policy Coordination Entity devices’ inter-dependencies resource availability inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements ◦ feedback on resource availability Distributed control model • constraint assertion QoS requirements set constraint on local policies
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction User−space ◦ fine-details, low-overhead QoS • coordination entity requirements user−space ◦ exploit system-wide view Global ◦ track resource availability and policy Coordination Entity devices’ inter-dependencies resource availability inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements Distributed control model ◦ feedback on resource availability • constraint assertion QoS requirements set constraint on local policies
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction User−space ◦ fine-details, low-overhead QoS • coordination entity requirements user−space ◦ exploit system-wide view Global Constraint ◦ track resource availability and policy Coordination Entity Aggregation devices’ inter-dependencies resource availability tuning inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements Distributed control model ◦ feedback on resource availability • constraint assertion QoS requirements set constraint on local policies
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support The PM QoS interface Linux kernel infrastructure to implement a coordination mechanism among drivers (capabilities) and application (QoS requirements) • Developed by Intel for iwl4965 WiFi driver on x86 ◦ since Linux 2.6.25 (linux/pm qos params.h) • Defines a (limited) set of “abstract” QoS parameters ◦ i.e. latencies, timeouts and throughput ◦ maintains a list of QoS requests and aggregate requirements • restrictive aggregation only, i.e. Min/Max • this aggregation generates a constraint ◦ provides notification chain for constraint update • drivers subscribe to parameters of interests e.g. CPUidle is constrained by ’system latency’ ◦ Drivers’ local policies should grant required constraints • no failures handling on notify chain calls
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS pm_qos current OPTIMAL Additive 20Mb/s MAX Constraint 54Mb/s value
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS pm_qos_update_requirement(bw,18) max(18,20) pm_qos current OPTIMAL Additive 20+18 Mb/s MAX 20Mb/s 38Mb/s 54Mb/s Constraint value
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS pm_qos_update_requirement(bw,18) max(18,20) pm_qos_update_requirement(bw,32) max(20,32) pm_qos current 32Mb/s OPTIMAL Additive 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS E1 E2 QoS pm_qos_update_requirement(bw,18) max(18,20) pm_qos_update_requirement(bw,32) max(20,32) pm_qos current 32Mb/s pm_qos Constraint OPTIMAL current Additive value 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS E1 E2 QoS pm_qos_update_requirement(bw,18) pm_qos_update_requirement max(18,20) notification pm_qos_update_requirement(bw,32) max(20,32) pm_qos current 32Mb/s pm_qos Constraint OPTIMAL Additive value 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS E1 E2 QoS pm_qos_update_requirement(bw,18) pm_qos_update_requirement max(18,20) notification pm_qos_update_requirement(bw,32) "grant" max(20,32) pm_qos current 32Mb/s pm_qos Constraint OPTIMAL Additive unuseful restrictive setting granted value value 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
Introduction Motivations Proposal Conclusions Where are we going? Our Goals • Define a formal model for system-wide performance vs power control ◦ based on constraints-based approach ◦ drivers could collaborate to find the optimal system-wide configuration with respect to all QoS requirements ◦ support multi-objective optimizations • Implementation based on latest Linux kernel ◦ overcoming current QoSPM limitations • Validate the model and the implementation on real hardware ◦ STM’s Nomadik platform ◦ evaluate overheads and performances
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control • Devices’ local control Framework • Abstracting reality • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control • Devices’ local control Framework • Abstracting reality Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control global Optimization Layer policy • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Execution Context Applications Hierarchical Distributed Libraries Buses Control QoS Requirements global Optimization Layer policy • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Execution Context Applications Hierarchical Distributed Libraries Buses Control QoS Requirements Distributed global Agreement Optimization Layer policy Manager • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Abstraction Layer System-Wide Metric (SWM) A parameter describing the behaviors of a running system and used to track resources availability • QoS requirements: are expressed as validity ranges on SWM mainly upper/lower bounds • Different abstraction levels ◦ Abstract System-wide Metric (ASM), platform independent exposed to user-land e.g. ambient light/noise, power source, specific application requirements ◦ Platform System-wide Metric (PSM), platform dependent private to platform code and platform drivers e.g. bus bandwidth, devices’ latency • Allow to track QoS inter-dependencies ◦ platform drivers and code can translate ASM’s requirements into PSM’s constraints Code Example
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Abstraction Layer Device Working Region (DWR) working d3 regions p2 The mapping on SWMs’ range of a device operating mode π26 C 33 π25 • A device could have different π24 C 31 working modes π23 ◦ different QoS => different π22 SWM range C 32 π21 • Defined by the device driver • Implicitly allows devices p1 dependencies tracking π11 π12 π13 π14 • Graphic representation A device with 3 DWR (cdm ) mapping 2 SWM (pi ) Code Example
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Modelling Layer Feasible System-wide Configurations (FSC) working d1 d2 d3 regions p2 The intersection of a least a DWR for each device C 23 FSC 3 C 33 • QoS requirements within a FSC C 31 FSC 1 ◦ all devices can support the C 22 required QoS level ◦ no conflicts C 32 FSC 2 • identify all and only the feasible system’s working modes C 21 ◦ all the possible solutions for the C 11 C 12 p1 PM optimization problem ◦ define an abstract model for The 3 FSCs existing on this system system-wide optimizations
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer A Formal Optimization Framework • Using Linear Programming (LP) ◦ well known mathematical multi-objective optimization framework • Two-fold goal ◦ formally justify the proposal • through the equivalence with a well known exact method for optimal solution search ◦ guide the design of an efficient implementation • we don’t want to solve an LP problem • identify possible simplifications • exploit problem specificities Use LP formulation to identify a solution-equivalent and efficient optimization strategy Go to Formulation
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 2. FSC identification C 23 3. Constraint aggregation C 33 4. FSC validation 5. FSC selection C 31 ◦ optimization policy − → og C 22 • Different time domains C 32 ◦ boot-time: steps 1-2 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 2. FSC identification C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation 5. FSC selection C 31 FSC 1 ◦ optimization policy − → og C 22 • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 FSC 1 ◦ optimization policy − → og C 22 • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 v3 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 FSC 1 ◦ optimization policy − → og C 22 Convex−Hall • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 v3 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification O’ C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 O FSC 1 ◦ optimization policy − → og C 22 Convex−Hall og • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 o2 v3 ◦ run-time: steps 3-5 C 21 o1 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification O’ C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 O FSC 1 ◦ optimization policy − → og C 22 Convex−Hall og • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 o2 v3 ◦ run-time: steps 3-5 C 21 o1 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification O’ C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 O FSC 1 ◦ optimization policy − → og C 22 Convex−Hall og • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 o2 v3 ◦ run-time: steps 3-5 C 21 o1 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts A Real Optimization Framework • Translate the formal (LP) model into an efficient implementation • Exploit tree different time domains ◦ boot time => FSC Identification (FI) ◦ policy update time => FSC Ordering (FO) ◦ constraint assertion time => FSC Selection (FS) • Support complexity partitioning ◦ high-overhead operations (FI) are executed once • Modular design ◦ split operations on “governor” and policy ◦ better support operation optimization • off-line computation (FI) • HW acceleration, e.g. look-up based implementation (FO, FS) Go to Overheads Graph
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
Introduction Motivations Proposal Conclusions Conclusions and Future Work Resuming the Proposal • Distributed approach for performances vs power trade-off control ◦ supports constraint based PM ◦ scalable on upcoming more and more complex architectures ◦ provides multi-objective optimizations • Layered design ◦ optimization layer on top of an abstraction layer ◦ improved code reuse and portability • Simple platform code and drivers interface ◦ few modifications required ◦ easily exploits platform and devices fine-details • Validated using a formal optimization model • Up-to-date implementation, rebased on mainline Linux kernel ◦ providing a sysfs interface and some dummy test modules to support testing and benchmarking
Introduction Motivations Proposal Conclusions Conclusions and Future Work Looking Forward • The implementation is going to be released in ML for RFC ◦ basic implementation of the designed software architecture ◦ public GIT repository: still missing! ◦ discuss, review, rework. . . community feedbacks are welcome! • Find real-world applications ◦ the constrained PM concept should be pushed . . . the QoS PM interface is almost unused ◦ try it: it’s free! • Provide guidelines for DWR definition ◦ distributed control assign different target to different levels ◦ local policies should fit well within the model • Improve the user-space interface ◦ integration within a resource management system framework ◦ automate constraint assertion • Investigate on HW acceleration possibilities
Add-ons Q&A
Add-ons Linear Programming (LP) Formulation • The PM optimization problem can be formulated as an LP problem • LP elements: ◦ solution space – SWMs Domain ◦ objective function – vector representing QoS optimization directions ◦ constraints – QoS requirements • dynamically reduce the number of valid FSCs ◦ convex hall – the smallest convex polygon including all valid FSCs ◦ valid solution – every point inside the convex hall ◦ optimal solutions – vertexes or edges of the convex hall • can always be mapped to 1 or 2 FSCs Go to Motivations
Add-ons CPM Overheads • Worst-Case Analysis ◦ synthetic drivers to configure the worst operating conditions ◦ running on VirtualBox, host: Intel Core 2@1.6GHz ◦ note: non-Cartesian logarithmic X axis Hoverheads % wrt 60s timeframe Go to Implementation Notes
Add-ons Implementation Summary $ git diff 4be3bd78.. --stat Documentation/cpm/00-INDEX.txt | 61 + Documentation/cpm/core.txt | 264 +++ Documentation/cpm/governors.txt | 146 ++ Documentation/cpm/overview.txt | 131 ++ Documentation/cpm/platform.txt | 123 ++ Documentation/cpm/policies.txt | 131 ++ Documentation/cpm/testing.txt | 67 + Documentation/cpm/user-guide.txt | 139 ++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/cpm/Kconfig | 112 ++ drivers/cpm/Makefile | 10 + drivers/cpm/cpm_core.c | 3402 +++++++++++++++++++++++++++++++++ drivers/cpm/cpm_governor_exhaustive.c | 420 ++++ drivers/cpm/cpm_policy_dummy.c | 122 ++ drivers/cpm/cpm_policy_performance.c | 199 ++ drivers/cpm/test/Kconfig | 38 + drivers/cpm/test/Makefile | 7 + drivers/cpm/test/cpm_test_bandwidth.c | 218 +++ drivers/cpm/test/cpm_test_dummy.c | 459 +++++ drivers/cpm/test/cpm_test_mp3gsm.c | 316 +++ include/linux/cpm.h | 491 +++++ 22 files changed, 6859 insertions(+), 0 deletions(-)
Add-ons Example - System-Wide Metrics Definitions // SWM Identifiers definitions #define SWM_AMBA_BANDWIDTH CPM_ASM_TOT+0 #define SWM_ADSP_CLK CPM_ASM_TOT+1 // Platform specific SWM (PSM) definition struct cpm_swm cpm_platform_psm[] = { CPM_PLATFORM_SWM("AMBA_BANDWIDTH", CPM_TYPE_GIB, CPM_USER_RW, CPM_COMPOSITION_ADDITIVE, 0, 8000), CPM_PLATFORM_SWM("ADSP_CLK", CPM_TYPE_GIB, CPM_USER_RO, CPM_COMPOSITION_ADDITIVE, 0, 266), }; // PSM Registration struct cpm_platform_data cpm_platform_data = { .swms = cpm_platform_psm, .count = ARRAY_SIZE(cpm_platform_psm), }; cpm_register_platform_psms(&cpm_platform_data); Go to Definition
Add-ons Example - Device Working Region struct cpm_swm_range vdsp_dwr0_ranges[] = { /* V-DSP MPEG4 decoding mode */ DEV_DWR_ASM(CPM_VCODEC, 1, 1, CPM_ASM_TYPE_RANGE), DEV_DWR_ASM(CPM_DSP_CLK, 40, 132, CPM_ASM_TYPE_RANGE), }; struct cpm_swm_range vdsp_dwr1_ranges[] = { /* V-DSP OFF mode */ DEV_DWR_ASM(CPM_VCODEC, 0, 0, CPM_ASM_TYPE_RANGE), DEV_DWR_ASM(CPM_DSP_CLK, 0, 132, CPM_ASM_TYPE_RANGE), }; struct cpm_dev_dwr vdsp_dwrs_list[] = { /* V-DSP working mode */ DEV_DWR("Mpeg4", vdsp_dwr0_ranges, ARRAY_SIZE(vdsp_dwr0_ranges)), DEV_DWR("OFF", vdsp_dwr1_ranges, ARRAY_SIZE(vdsp_dwr1_ranges)), }; static struct cpm_dev_data vdsp_data = { /* V-DSP DWR’s registration */ .notifier_callback = vdsp_cpm_callback, .dwrs = vdsp_dwrs_list, .dwrs_count = ARRAY_SIZE(vdsp_dwrs_list), }; ret = cpm_register_device(&vdsp.dev, &vdsp_data); Go to Definition
Add-ons Example - Real Use-Case • Youtube and Torrent ◦ 3 ASM: • acodec, vcodec, bandwidth ◦ 2 PSM: • cpu freq, cpu dsp platform ◦ devices(dwr): • modem(5), vcodec(4), acodec(4), cpu(7), platform(7) ◦ Identified FSC: 415 • 10% out of 3920 of worst case analysis

More Related Content

PDF
System on Chip (SoC) for mobile phones
byJeffrey Funk
 
PPTX
Meeting SEP 2.0 Compliance: Developing Power Aware Embedded Systems for the M...
bymentoresd
 
PDF
The Guardian
byAl Asbab FZ LLC
 
PDF
Roy omap validation_dvc_lub_092106
byObsidian Software
 
PDF
Power Systems 2009 Hardware
byAndrey Klyachkin
 
PPT
Challenges in mixed signal
bychiportal
 
PPT
SoC Design
byVinChip Systems - VinTrain VLSI Academy
 
PDF
05 2012 power_roadshow_software_on_power
byGennaro (Rino) Persico
 
System on Chip (SoC) for mobile phones
byJeffrey Funk
 
Meeting SEP 2.0 Compliance: Developing Power Aware Embedded Systems for the M...
bymentoresd
 
The Guardian
byAl Asbab FZ LLC
 
Roy omap validation_dvc_lub_092106
byObsidian Software
 
Power Systems 2009 Hardware
byAndrey Klyachkin
 
Challenges in mixed signal
bychiportal
 
SoC Design
byVinChip Systems - VinTrain VLSI Academy
 
05 2012 power_roadshow_software_on_power
byGennaro (Rino) Persico
 

What's hot

PPTX
System-on-Chip Programmable Retina
byVanya Valindria
 
PDF
Cisco Unified Computing Systems Update
byCisco Canada
 
PDF
SDN
byNimit Shishodia
 
PDF
101 cd 1415-1445
byChiou-Nan Chen
 
PDF
Cots moves to multicore: Wind River
byKonrad Witte
 
PPTX
E Vm Virtualization
byArturo Saavedra
 
PDF
CELC_Новые возможности Cisco UCS
byCisco Russia
 
PPT
Arista @ HPC on Wall Street 2012
byKazunori Sato
 
PDF
Ortem Electronics 2011
byayavuz
 
PDF
Benefits of Using FPGAs for Embedded Processing: Embedded World 2010
byAltera Corporation
 
System-on-Chip Programmable Retina
byVanya Valindria
 
Cisco Unified Computing Systems Update
byCisco Canada
 
SDN
byNimit Shishodia
 
101 cd 1415-1445
byChiou-Nan Chen
 
Cots moves to multicore: Wind River
byKonrad Witte
 
E Vm Virtualization
byArturo Saavedra
 
CELC_Новые возможности Cisco UCS
byCisco Russia
 
Arista @ HPC on Wall Street 2012
byKazunori Sato
 
Ortem Electronics 2011
byayavuz
 
Benefits of Using FPGAs for Embedded Processing: Embedded World 2010
byAltera Corporation
 

Viewers also liked

PDF
Evoluzione dei Sistemi Embedded: Verso architetture multi-core
byPatrick Bellasi
 
PDF
Cross-Layer Frameworks for Constrained Power and Resources Management of Embe...
byPatrick Bellasi
 
ODP
U boot source clean up project how-to
byMacpaul Lin
 
PDF
U boot 程式碼打掃計畫
byMacpaul Lin
 
PDF
How to build a community in a company blue&macpaul coscup2015
byMacpaul Lin
 
PDF
Linux Power Management Slideshare
byPatrick Bellasi
 
PDF
Embedded Systems Power Management
byPatrick Bellasi
 
PPT
Bootstrap process of u boot (NDS32 RISC CPU)
byMacpaul Lin
 
PPTX
USB Specification 2.0 - Chapter 9 - Device Framework
byMacpaul Lin
 
PPT
U boot porting guide for SoC
byMacpaul Lin
 
PDF
Linux Porting to a Custom Board
byPatrick Bellasi
 
PDF
Exploiting Linux Control Groups for Effective Run-time Resource Management
byPatrick Bellasi
 
PDF
Embedded Linux from Scratch to Yocto
bySherif Mousa
 
PDF
Building Mini Embedded Linux System for X86 Arch
bySherif Mousa
 
Evoluzione dei Sistemi Embedded: Verso architetture multi-core
byPatrick Bellasi
 
Cross-Layer Frameworks for Constrained Power and Resources Management of Embe...
byPatrick Bellasi
 
U boot source clean up project how-to
byMacpaul Lin
 
U boot 程式碼打掃計畫
byMacpaul Lin
 
How to build a community in a company blue&macpaul coscup2015
byMacpaul Lin
 
Linux Power Management Slideshare
byPatrick Bellasi
 
Embedded Systems Power Management
byPatrick Bellasi
 
Bootstrap process of u boot (NDS32 RISC CPU)
byMacpaul Lin
 
USB Specification 2.0 - Chapter 9 - Device Framework
byMacpaul Lin
 
U boot porting guide for SoC
byMacpaul Lin
 
Linux Porting to a Custom Board
byPatrick Bellasi
 
Exploiting Linux Control Groups for Effective Run-time Resource Management
byPatrick Bellasi
 
Embedded Linux from Scratch to Yocto
bySherif Mousa
 
Building Mini Embedded Linux System for X86 Arch
bySherif Mousa
 

Similar to Constrained Power Management

PDF
Pci express3-device-architecture-optimizations-idf2009-presentation
byjkcontee
 
PDF
Chip ex 2011 faraday
bychiportal
 
PDF
Embedded Systems Engineering section
byeselab
 
PPT
Modeling System Behaviors: A Better Paradigm on Prototyping
byDVClub
 
PDF
2011 Feb07 Lewis Prospectus
byawadelewis
 
PPT
Power Optimization Through Manycore Multiprocessing
bychiportal
 
PDF
MDE based FPGA physical Design Fast prototyping with Smalltalk
byESUG
 
PDF
OMAP Verification
byDVClub
 
PDF
Fault tolerant platforms for manufacturing applications
byARC Advisory Group
 
PDF
Sharam salamian
byObsidian Software
 
PDF
Introduction to Microcontroller
byPantech ProLabs India Pvt Ltd
 
PDF
Introduction to Microcontroller
byPantech ProLabs India Pvt Ltd
 
PDF
Ourdev 598703 tpwcm7
byzrx737
 
PPTX
VVDN Presentation
byvibansal
 
PPTX
Intro (lesson1)comp arch
byRoger Duran
 
PDF
DFX Architecture for High-performance Multi-core Microprocessors
byIshwar Parulkar
 
PDF
Approaches for Power Management Verification of SOC
byDVClub
 
PPT
Analyzing Chips in a System Context
bychiportal
 
PDF
Shultz dallas q108
byObsidian Software
 
PDF
Schulz dallas q1_2008
byObsidian Software
 
Pci express3-device-architecture-optimizations-idf2009-presentation
byjkcontee
 
Chip ex 2011 faraday
bychiportal
 
Embedded Systems Engineering section
byeselab
 
Modeling System Behaviors: A Better Paradigm on Prototyping
byDVClub
 
2011 Feb07 Lewis Prospectus
byawadelewis
 
Power Optimization Through Manycore Multiprocessing
bychiportal
 
MDE based FPGA physical Design Fast prototyping with Smalltalk
byESUG
 
OMAP Verification
byDVClub
 
Fault tolerant platforms for manufacturing applications
byARC Advisory Group
 
Sharam salamian
byObsidian Software
 
Introduction to Microcontroller
byPantech ProLabs India Pvt Ltd
 
Introduction to Microcontroller
byPantech ProLabs India Pvt Ltd
 
Ourdev 598703 tpwcm7
byzrx737
 
VVDN Presentation
byvibansal
 
Intro (lesson1)comp arch
byRoger Duran
 
DFX Architecture for High-performance Multi-core Microprocessors
byIshwar Parulkar
 
Approaches for Power Management Verification of SOC
byDVClub
 
Analyzing Chips in a System Context
bychiportal
 
Shultz dallas q108
byObsidian Software
 
Schulz dallas q1_2008
byObsidian Software
 

Recently uploaded

PDF
Governing Agentic Enterprise - From Shadow AI to Autonomous Security.pdf
bysajjasridhar1990
 
PDF
Presentation on Four Stroke Engine of Ic engine
bySonam Sherpa
 
PDF
Mobile Onboarding UX 11 Best Practices for Retention (2026).pdf
byDesign Studio UI UX
 
PDF
Best-Travel-Portal-Development-Solutions-for-Online-Growth
bykashishnagarrajput
 
PPTX
Oracle SCM Cloud Solutions for Smart Supply Chain Management
byChetu
 
PPTX
Design Flaws and Known Attacks in Agentic AI - ITI Business Session
byInformation Technology Institute
 
PPTX
Lecture 04. about Black heads and Hackerss.pptx
byvinocol222
 
PDF
Using Change Data Capture (CDC) to Ingest Data into Apache Kafka
byGiovanni Marigi
 
PDF
A "Kill Switch" (Emergency Off Switch) for AI?
byScott M. Graffius
 
PDF
Higgsfield AI: The New Way to Create Cinematic Video
bytechnologyupside
 
PDF
Best Bank Statement Converter Software - A Documentation-Based Meta-Analysis ...
bylewisconrada
 
PDF
TrustArc Webinar - Unpacking India’s DPDP Act: What You Should Know
byTrustArc
 
PDF
Saga: The new era of transactions in a microservices architecture
byGiovanni Marigi
 
PPTX
Unit 1 Introduction of Computer Networks
bySuvarnaSharma5
 
PPTX
UNIT 1- Introduction to Basic of Computer Fundamentals
bypawarbhaktiit
 
PPTX
How Blockchain Application Development Enables Trustless Digital Ecosystems.pptx
byLisa ward
 
PDF
Generating Structured Outputs from Unstructured Content Using LLMs
byEnterprise Knowledge
 
PDF
Early Signs of Constraint Loss in Modern System Design
byReality Drift Archive
 
PDF
DataLiva-LivaGRC- Business Software for Governance, Risk, and Compliance
byMustafa Kuğu
 
PDF
65 AI-related Posts Catalog https://tinyurl.com/mpavkr8z
byBob Marcus
 
Governing Agentic Enterprise - From Shadow AI to Autonomous Security.pdf
bysajjasridhar1990
 
Presentation on Four Stroke Engine of Ic engine
bySonam Sherpa
 
Mobile Onboarding UX 11 Best Practices for Retention (2026).pdf
byDesign Studio UI UX
 
Best-Travel-Portal-Development-Solutions-for-Online-Growth
bykashishnagarrajput
 
Oracle SCM Cloud Solutions for Smart Supply Chain Management
byChetu
 
Design Flaws and Known Attacks in Agentic AI - ITI Business Session
byInformation Technology Institute
 
Lecture 04. about Black heads and Hackerss.pptx
byvinocol222
 
Using Change Data Capture (CDC) to Ingest Data into Apache Kafka
byGiovanni Marigi
 
A "Kill Switch" (Emergency Off Switch) for AI?
byScott M. Graffius
 
Higgsfield AI: The New Way to Create Cinematic Video
bytechnologyupside
 
Best Bank Statement Converter Software - A Documentation-Based Meta-Analysis ...
bylewisconrada
 
TrustArc Webinar - Unpacking India’s DPDP Act: What You Should Know
byTrustArc
 
Saga: The new era of transactions in a microservices architecture
byGiovanni Marigi
 
Unit 1 Introduction of Computer Networks
bySuvarnaSharma5
 
UNIT 1- Introduction to Basic of Computer Fundamentals
bypawarbhaktiit
 
How Blockchain Application Development Enables Trustless Digital Ecosystems.pptx
byLisa ward
 
Generating Structured Outputs from Unstructured Content Using LLMs
byEnterprise Knowledge
 
Early Signs of Constraint Loss in Modern System Design
byReality Drift Archive
 
DataLiva-LivaGRC- Business Software for Governance, Risk, and Compliance
byMustafa Kuğu
 
65 AI-related Posts Catalog https://tinyurl.com/mpavkr8z
byBob Marcus
 

Constrained Power Management

  • 1.
    Introduction Motivations Proposal Conclusions Constrained Power Management an holistic approach to power management Patrick Bellasi PhD Student Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy ELC-E - October, 15-16 2009
  • 2.
    Introduction Motivations Proposal Conclusions Focusing the presentation’s topic Outline • Highlight some issues of current Linux kernel PM support • Advance a proposal to tackle these problems ◦ not a finale solution ◦ try to focus attention on the topic ◦ trigger a discussion to improve this kind of support
  • 3.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct applications input • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s LCD ACodec WiFi specific dependencies ◦ dependency tree Simple representation of a complex system
  • 4.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct applications input PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
  • 5.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct applications input PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
  • 6.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
  • 7.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
  • 8.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
  • 9.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system
  • 10.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system Multiple disjoint policies
  • 11.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Power Management Techniques • Focusing on devices and interconnections ◦ almost any direct S/R Clk V/I applications input Framework Framework Framework PASR • Device specific’s policies ◦ multiple policies for MEM SYS BUSC single device BUS CPU BUSA BUSB • System-wide Policies ◦ tracks subsystem’s CPUfreq CPUidle LCD ACodec WiFi specific dependencies Backlight AP Negotiation ◦ dependency tree Simple representation of a complex system Multiple disjoint policies How can we achieve system-wide optimization?
  • 12.
    Introduction Motivations Proposal Conclusions Multiple sub-system specific policies Multiple-Policy Approach: Potential Issues • Multiple decision points ◦ difficult inter-dependencies tracking ◦ risk of conflicting decisions • Only indirect info about applications QoS requirements ◦ user-space know the requirements, kernel should support them ◦ application requirements should drive kernel frameworks tuning • No proper aggregation on applications requirements ◦ only some frameworks provide it (e.g V/I fw, “new” clock fw) ◦ risk of code duplication • No feed-back on resources availability ◦ applications could require resources from multiple devices ◦ behavior depends on effective availability of all the required resources The composition of almost independent optimization policies cannot grant a system-wide optimization
  • 13.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction ◦ fine-details, low-overhead • coordination entity ◦ exploit system-wide view ◦ track resource availability and devices’ inter-dependencies • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements ◦ feedback on resource availability Distributed control model • constraint assertion QoS requirements set constraint on local policies
  • 14.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction ◦ fine-details, low-overhead • coordination entity ◦ exploit system-wide view ◦ track resource availability and Coordination Entity devices’ inter-dependencies resource availability inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements ◦ feedback on resource availability Distributed control model • constraint assertion QoS requirements set constraint on local policies
  • 15.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction ◦ fine-details, low-overhead • coordination entity ◦ exploit system-wide view Global ◦ track resource availability and policy Coordination Entity devices’ inter-dependencies resource availability inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements ◦ feedback on resource availability Distributed control model • constraint assertion QoS requirements set constraint on local policies
  • 16.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction User−space ◦ fine-details, low-overhead QoS • coordination entity requirements user−space ◦ exploit system-wide view Global ◦ track resource availability and policy Coordination Entity devices’ inter-dependencies resource availability inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements Distributed control model ◦ feedback on resource availability • constraint assertion QoS requirements set constraint on local policies
  • 17.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Constrained Power Management • drivers’ local policies ◦ targeted to power reduction User−space ◦ fine-details, low-overhead QoS • coordination entity requirements user−space ◦ exploit system-wide view Global Constraint ◦ track resource availability and policy Coordination Entity Aggregation devices’ inter-dependencies resource availability tuning inter−dependency • global optimization policy Local ◦ multi-objective, low-frequency Drivers policies • single user-space interface ◦ collects QoS requirements Distributed control model ◦ feedback on resource availability • constraint assertion QoS requirements set constraint on local policies
  • 18.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support The PM QoS interface Linux kernel infrastructure to implement a coordination mechanism among drivers (capabilities) and application (QoS requirements) • Developed by Intel for iwl4965 WiFi driver on x86 ◦ since Linux 2.6.25 (linux/pm qos params.h) • Defines a (limited) set of “abstract” QoS parameters ◦ i.e. latencies, timeouts and throughput ◦ maintains a list of QoS requests and aggregate requirements • restrictive aggregation only, i.e. Min/Max • this aggregation generates a constraint ◦ provides notification chain for constraint update • drivers subscribe to parameters of interests e.g. CPUidle is constrained by ’system latency’ ◦ Drivers’ local policies should grant required constraints • no failures handling on notify chain calls
  • 19.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS pm_qos current OPTIMAL Additive 20Mb/s MAX Constraint 54Mb/s value
  • 20.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS pm_qos_update_requirement(bw,18) max(18,20) pm_qos current OPTIMAL Additive 20+18 Mb/s MAX 20Mb/s 38Mb/s 54Mb/s Constraint value
  • 21.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS pm_qos_update_requirement(bw,18) max(18,20) pm_qos_update_requirement(bw,32) max(20,32) pm_qos current 32Mb/s OPTIMAL Additive 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
  • 22.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS E1 E2 QoS pm_qos_update_requirement(bw,18) max(18,20) pm_qos_update_requirement(bw,32) max(20,32) pm_qos current 32Mb/s pm_qos Constraint OPTIMAL current Additive value 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
  • 23.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS E1 E2 QoS pm_qos_update_requirement(bw,18) pm_qos_update_requirement max(18,20) notification pm_qos_update_requirement(bw,32) max(20,32) pm_qos current 32Mb/s pm_qos Constraint OPTIMAL Additive value 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
  • 24.
    Introduction Motivations Proposal Conclusions Emerging system-wide optimization support Limitations of the PM QoS Interface “The notion of constraint based PM has been rattling around for a while now. PMQoS is just an early application of it. I think a lot more could be done in this area.” M. Gross ◦ Missing support for platform-specific parameters ◦ No additive constraints concepts support ◦ Only best-effort approach E1 E2 QoS E1 E2 QoS pm_qos_update_requirement(bw,18) pm_qos_update_requirement max(18,20) notification pm_qos_update_requirement(bw,32) "grant" max(20,32) pm_qos current 32Mb/s pm_qos Constraint OPTIMAL Additive unuseful restrictive setting granted value value 20+18 Mb/s MAX 38+32 Mb/s 20Mb/s 38Mb/s 54Mb/s 70Mb/s Constraint value
  • 25.
    Introduction Motivations Proposal Conclusions Where are we going? Our Goals • Define a formal model for system-wide performance vs power control ◦ based on constraints-based approach ◦ drivers could collaborate to find the optimal system-wide configuration with respect to all QoS requirements ◦ support multi-objective optimizations • Implementation based on latest Linux kernel ◦ overcoming current QoSPM limitations • Validate the model and the implementation on real hardware ◦ STM’s Nomadik platform ◦ evaluate overheads and performances
  • 26.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control • Devices’ local control Framework • Abstracting reality • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
  • 27.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control • Devices’ local control Framework • Abstracting reality Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
  • 28.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
  • 29.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Hierarchical Distributed Control global Optimization Layer policy • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
  • 30.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Execution Context Applications Hierarchical Distributed Libraries Buses Control QoS Requirements global Optimization Layer policy • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
  • 31.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Architecture Abstracting the Reality, Modeling the Abstraction Execution Context Applications Hierarchical Distributed Libraries Buses Control QoS Requirements Distributed global Agreement Optimization Layer policy Manager • Devices’ local control Framework Modelling Layer • Abstracting reality FSC Abstraction Layer DWR PSM/ASM DWR • Modeling Abstraction Device Local local local • Model optimization Control policy Driver Platform Code Driver policy • Considering QoS Device Device requirements Key: piece of information device/tool abstraction information flow • Constraint local policies
  • 32.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Abstraction Layer System-Wide Metric (SWM) A parameter describing the behaviors of a running system and used to track resources availability • QoS requirements: are expressed as validity ranges on SWM mainly upper/lower bounds • Different abstraction levels ◦ Abstract System-wide Metric (ASM), platform independent exposed to user-land e.g. ambient light/noise, power source, specific application requirements ◦ Platform System-wide Metric (PSM), platform dependent private to platform code and platform drivers e.g. bus bandwidth, devices’ latency • Allow to track QoS inter-dependencies ◦ platform drivers and code can translate ASM’s requirements into PSM’s constraints Code Example
  • 33.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Abstraction Layer Device Working Region (DWR) working d3 regions p2 The mapping on SWMs’ range of a device operating mode π26 C 33 π25 • A device could have different π24 C 31 working modes π23 ◦ different QoS => different π22 SWM range C 32 π21 • Defined by the device driver • Implicitly allows devices p1 dependencies tracking π11 π12 π13 π14 • Graphic representation A device with 3 DWR (cdm ) mapping 2 SWM (pi ) Code Example
  • 34.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Modelling Layer Feasible System-wide Configurations (FSC) working d1 d2 d3 regions p2 The intersection of a least a DWR for each device C 23 FSC 3 C 33 • QoS requirements within a FSC C 31 FSC 1 ◦ all devices can support the C 22 required QoS level ◦ no conflicts C 32 FSC 2 • identify all and only the feasible system’s working modes C 21 ◦ all the possible solutions for the C 11 C 12 p1 PM optimization problem ◦ define an abstract model for The 3 FSCs existing on this system system-wide optimizations
  • 35.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer A Formal Optimization Framework • Using Linear Programming (LP) ◦ well known mathematical multi-objective optimization framework • Two-fold goal ◦ formally justify the proposal • through the equivalence with a well known exact method for optimal solution search ◦ guide the design of an efficient implementation • we don’t want to solve an LP problem • identify possible simplifications • exploit problem specificities Use LP formulation to identify a solution-equivalent and efficient optimization strategy Go to Formulation
  • 36.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 2. FSC identification C 23 3. Constraint aggregation C 33 4. FSC validation 5. FSC selection C 31 ◦ optimization policy − → og C 22 • Different time domains C 32 ◦ boot-time: steps 1-2 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 37.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 2. FSC identification C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation 5. FSC selection C 31 FSC 1 ◦ optimization policy − → og C 22 • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 38.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 FSC 1 ◦ optimization policy − → og C 22 • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 v3 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 39.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 FSC 1 ◦ optimization policy − → og C 22 Convex−Hall • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 v3 ◦ run-time: steps 3-5 C 21 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 40.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification O’ C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 O FSC 1 ◦ optimization policy − → og C 22 Convex−Hall og • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 o2 v3 ◦ run-time: steps 3-5 C 21 o1 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 41.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification O’ C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 O FSC 1 ◦ optimization policy − → og C 22 Convex−Hall og • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 o2 v3 ◦ run-time: steps 3-5 C 21 o1 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 42.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - The Optimization Layer Putting it All Together working 1. DWRs registration d1 d2 d3 regions p2 v1 2. FSC identification O’ C 23 3. Constraint aggregation FSC 3 C 33 4. FSC validation π2M v3 5. FSC selection C 31 O FSC 1 ◦ optimization policy − → og C 22 Convex−Hall og • Different time domains C 32 FSC 2 ◦ boot-time: steps 1-2 o2 v3 ◦ run-time: steps 3-5 C 21 o1 • step 5 can be simplified C 11 C 12 p1 by FSC pre-ordering π1c π1M ◦ policy defined e.g. FSC3 , FSC1 , FSC2
  • 43.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts A Real Optimization Framework • Translate the formal (LP) model into an efficient implementation • Exploit tree different time domains ◦ boot time => FSC Identification (FI) ◦ policy update time => FSC Ordering (FO) ◦ constraint assertion time => FSC Selection (FS) • Support complexity partitioning ◦ high-overhead operations (FI) are executed once • Modular design ◦ split operations on “governor” and policy ◦ better support operation optimization • off-line computation (FI) • HW acceleration, e.g. look-up based implementation (FO, FS) Go to Overheads Graph
  • 44.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
  • 45.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
  • 46.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
  • 47.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
  • 48.
    Introduction Motivations Proposal Conclusions CPM in a Nutshell - Proof-of-Concepts Framework Design • framework core CPM Framework CPM Policies ◦ data types, ASM cpm_policy 2 register ◦ glue code cpm_sysfs cpm_governor ◦ user-space API • platform code 4 update cpm_core 7 monitor ◦ PSM definition 1 register 3 subscribe • device drivers Device Drivers Platform Code 5 update_request ◦ DWR definition cpm_data 6 notify driver ◦ constraints auth. • governor platform_code Legend ◦ FSC identification require framework integration export framework data provide framework implementation functional dependency direct call indirect call • policy ◦ FSC ordering Main framework components and their relationship ◦ constraints auth.
  • 49.
    Introduction Motivations Proposal Conclusions Conclusions and Future Work Resuming the Proposal • Distributed approach for performances vs power trade-off control ◦ supports constraint based PM ◦ scalable on upcoming more and more complex architectures ◦ provides multi-objective optimizations • Layered design ◦ optimization layer on top of an abstraction layer ◦ improved code reuse and portability • Simple platform code and drivers interface ◦ few modifications required ◦ easily exploits platform and devices fine-details • Validated using a formal optimization model • Up-to-date implementation, rebased on mainline Linux kernel ◦ providing a sysfs interface and some dummy test modules to support testing and benchmarking
  • 50.
    Introduction Motivations Proposal Conclusions Conclusions and Future Work Looking Forward • The implementation is going to be released in ML for RFC ◦ basic implementation of the designed software architecture ◦ public GIT repository: still missing! ◦ discuss, review, rework. . . community feedbacks are welcome! • Find real-world applications ◦ the constrained PM concept should be pushed . . . the QoS PM interface is almost unused ◦ try it: it’s free! • Provide guidelines for DWR definition ◦ distributed control assign different target to different levels ◦ local policies should fit well within the model • Improve the user-space interface ◦ integration within a resource management system framework ◦ automate constraint assertion • Investigate on HW acceleration possibilities
  • 51.
  • 52.
    Add-ons Linear Programming (LP)Formulation • The PM optimization problem can be formulated as an LP problem • LP elements: ◦ solution space – SWMs Domain ◦ objective function – vector representing QoS optimization directions ◦ constraints – QoS requirements • dynamically reduce the number of valid FSCs ◦ convex hall – the smallest convex polygon including all valid FSCs ◦ valid solution – every point inside the convex hall ◦ optimal solutions – vertexes or edges of the convex hall • can always be mapped to 1 or 2 FSCs Go to Motivations
  • 53.
    Add-ons CPM Overheads • Worst-Case Analysis ◦ synthetic drivers to configure the worst operating conditions ◦ running on VirtualBox, host: Intel Core 2@1.6GHz ◦ note: non-Cartesian logarithmic X axis Hoverheads % wrt 60s timeframe Go to Implementation Notes
  • 54.
    Add-ons Implementation Summary $ git diff 4be3bd78.. --stat Documentation/cpm/00-INDEX.txt | 61 + Documentation/cpm/core.txt | 264 +++ Documentation/cpm/governors.txt | 146 ++ Documentation/cpm/overview.txt | 131 ++ Documentation/cpm/platform.txt | 123 ++ Documentation/cpm/policies.txt | 131 ++ Documentation/cpm/testing.txt | 67 + Documentation/cpm/user-guide.txt | 139 ++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/cpm/Kconfig | 112 ++ drivers/cpm/Makefile | 10 + drivers/cpm/cpm_core.c | 3402 +++++++++++++++++++++++++++++++++ drivers/cpm/cpm_governor_exhaustive.c | 420 ++++ drivers/cpm/cpm_policy_dummy.c | 122 ++ drivers/cpm/cpm_policy_performance.c | 199 ++ drivers/cpm/test/Kconfig | 38 + drivers/cpm/test/Makefile | 7 + drivers/cpm/test/cpm_test_bandwidth.c | 218 +++ drivers/cpm/test/cpm_test_dummy.c | 459 +++++ drivers/cpm/test/cpm_test_mp3gsm.c | 316 +++ include/linux/cpm.h | 491 +++++ 22 files changed, 6859 insertions(+), 0 deletions(-)
  • 55.
    Add-ons Example - System-WideMetrics Definitions // SWM Identifiers definitions #define SWM_AMBA_BANDWIDTH CPM_ASM_TOT+0 #define SWM_ADSP_CLK CPM_ASM_TOT+1 // Platform specific SWM (PSM) definition struct cpm_swm cpm_platform_psm[] = { CPM_PLATFORM_SWM("AMBA_BANDWIDTH", CPM_TYPE_GIB, CPM_USER_RW, CPM_COMPOSITION_ADDITIVE, 0, 8000), CPM_PLATFORM_SWM("ADSP_CLK", CPM_TYPE_GIB, CPM_USER_RO, CPM_COMPOSITION_ADDITIVE, 0, 266), }; // PSM Registration struct cpm_platform_data cpm_platform_data = { .swms = cpm_platform_psm, .count = ARRAY_SIZE(cpm_platform_psm), }; cpm_register_platform_psms(&cpm_platform_data); Go to Definition
  • 56.
    Add-ons Example - DeviceWorking Region struct cpm_swm_range vdsp_dwr0_ranges[] = { /* V-DSP MPEG4 decoding mode */ DEV_DWR_ASM(CPM_VCODEC, 1, 1, CPM_ASM_TYPE_RANGE), DEV_DWR_ASM(CPM_DSP_CLK, 40, 132, CPM_ASM_TYPE_RANGE), }; struct cpm_swm_range vdsp_dwr1_ranges[] = { /* V-DSP OFF mode */ DEV_DWR_ASM(CPM_VCODEC, 0, 0, CPM_ASM_TYPE_RANGE), DEV_DWR_ASM(CPM_DSP_CLK, 0, 132, CPM_ASM_TYPE_RANGE), }; struct cpm_dev_dwr vdsp_dwrs_list[] = { /* V-DSP working mode */ DEV_DWR("Mpeg4", vdsp_dwr0_ranges, ARRAY_SIZE(vdsp_dwr0_ranges)), DEV_DWR("OFF", vdsp_dwr1_ranges, ARRAY_SIZE(vdsp_dwr1_ranges)), }; static struct cpm_dev_data vdsp_data = { /* V-DSP DWR’s registration */ .notifier_callback = vdsp_cpm_callback, .dwrs = vdsp_dwrs_list, .dwrs_count = ARRAY_SIZE(vdsp_dwrs_list), }; ret = cpm_register_device(&vdsp.dev, &vdsp_data); Go to Definition
  • 57.
    Add-ons Example - RealUse-Case • Youtube and Torrent ◦ 3 ASM: • acodec, vcodec, bandwidth ◦ 2 PSM: • cpu freq, cpu dsp platform ◦ devices(dwr): • modem(5), vcodec(4), acodec(4), cpu(7), platform(7) ◦ Identified FSC: 415 • 10% out of 3920 of worst case analysis