Control Aspects in Adaptive Multicore CPU Management

1. Control Aspects in Adaptive MulticoreCPU Management Karl-Erik Årzén Dept of Automatic ControlLund University Based on joint work withVanessa Romero Segovia, Stefan Schorr, Gerhard Fohler, MikaelKralmark, Johan Eker and several others from the ACTORS project

2. ACTORS CPU • Adaptivity and Control of Resources in Embedded Systems • EU FP7 STREP project • 2008-2011 (Feb) • Coordinated by Ericsson (Johan Eker) • Lund University, TU Kaiserslautern, ScuolaSuperioreSant’Annadi Pisa, EPFL, AKAtech, Evidence • Media applications (soft real-time) for smart phones • Control applications

3. ACTORS: Key Ingredients • Data-Flow Programming • CAL Actor Language • Feedback-Based Resource Management • Control how much CPU resources that are allocated to different applications based on feedback from resource utilization and achieved QoS

4. 10 % 20 % 45 % 25 % ACTORS: Key Ingredients • Reservation-Based CPU Scheduling • SCHED_EDF • Partitioned multi-core EDF scheduler • Hard CBS reservations • Each reservation may containseveral threads • Hierarchical scheduler with SCHED_EDF tasks executing on a higher level than ordinary Linux tasks • Multicore Linux Platforms • ARM 11, x86 • Periodic Bandwidth Servers • Constant Bandwidth Server Virtual processors (VPs) Budget Period

5. Resource Manager Objectives • Adapt applications to changes in CPU resource availability • Change the application service level • Each application is assumed to support a discrete set of execution modes where a higher service level provides higher QoS and consumes more CPU resources • Adapt the resource distribution to changes in application requirements • Change the amount of resources allocated to an application

6. Overview • CAL Dataflow Applications • Dataflow run-time system • Legacy applications through wrapper • All threads within one VP DBusinterface • Resource Manager • C++ framework • DBus IPC to application • Control groups API to scheduler ControlGroupsinterface • SCHED_EDF hierarchical scheduler • Partitioned multi-core scheduler • Hard CBS Reservations • - one or several threads Cores

7. Static Information From applications to RM at registration: - Service Level Table - Thread IDs and how they should be grouped From system administrator to RM at startup: - Application Importance

8. Dynamic Inputs • Happiness: • boolean indicator of whether the QoS obtained corresponds to what could be expected at the current service level • Used Budget (Bandwidth): • average used budget • Exhaustion Percentage: • percentage of server periods in which the budget was exhausted

9. Outputs Service Level • Reservation Parameters: • Budget • Period • Affinity - RM may migrate VPs

10. Resource Manager Implementation • C++ • User space application • Two threads • Executes within a dedicated fixed-size virtual processor in one of the cores • Two parts: • Infrastructure • Control Logic • Interchangeable classes • 5 policies Infrastructure ControlLogic

11. Dataflow Analysis Partition 1 Partition 3 • Static partitioning • Automatic analysis for SCF/CSDF actors • Automatic merging of SDF/CSDF actors to improve run-time performance Partition 2 Partition 4

12. CAL Run-Time System • One thread per partition executing its actors using round-robin • One thread per “system actor” (IO, time) • The threads from the same partition are executed by the same virtual processor • If possible the VPs are mapped to different physical cores in order to enable parallel execution IO Thread VP Thread VP Core 2 Core 1

13. Resource Manager Functionality • Assign service levels • When applications register or unregister • Formulated as a ILP problem • Importance as weight • glpk solver • Mapping & bandwidth distribution • Map reservations to cores • Distribute the total BW to the reservations Two Approaches: • Spread out the VPs and balance the load • Pack the VPs in as few cores as possible • Allow turning off unused cores • Bin packing • At most 90% of each core is used for SCHED_EDF tasks

14. Resource Manager Functionality • Separate service level assignment and BW Distribution • The best service level assignment may lead to an unfeasible BW distribution • Approach 1: • New SL assignment that generates the next best solution • New BW Distribution • Approach 2: • Compress the individual VPs

15. Resource Manager Tasks • Bandwidth adaptation • Adjust the servers bandwidth dynamically based on measured resource usage and obtained happiness • If the application is unhappy the bandwidth is increased until the application is happy again EPSP EP Changes what is meant by sufficientlyclose based on EP: Changes the AB so that the UB lies sufficiently close: 15

16. Resource Manager Tasks • Multiple bandwidth adaptation strategies • Strategy 1: • A VP may never consume more bandwidththan what was originally assigned to it • BW controller may reduce the BW if not used • Strategy 2: • A VP may use more resources than originally assigned to it • If there are free resources available, or • If there are VPs of less important applications that use more BW than originally allocated to them • In the latter case the less important applications are compressed • All applications are always guaranteed to obtain their originally assigned values (can never be compressed beyond that) May only be reusedby ordinary Linux tasks May also be reusedby SCHED_EDF tasks

17. RM Support Software • GUI • VP to core assignment • AB, UB, and EP • Service Level Table • Event history • Itself an application under the control of the RM • Load Generator • Generates artificial load for testing • Application Wrapper • Wrapper for non-Actors aware applications

18. MPEG-4 Video Decoding Demonstrator • MPEG-4 SP decoder implemented in CAL • Connected to an Axis network camera • Service level changes results in commands from the decoderto the camera toreduce the frame rate and/or resolution • Shown in demo

19. MPEG-4 Video Decoding Demonstrator More important application started. SL decreased Application terminated. SL increased again Application unhappy

20. Feedback Control Demonstrator • Industrial robot balancingan inverted pendulum • Controller in CAL • Ball and Beam Processes • Controller in CAL • MPEG-4 Video Decoder • Service level changes correspondchanges in sampling period • Video available if someone is interested during the break

21. Video Quality Adaptation Demonstrator • Service level change correspond to request to video server to adapt the video quality • MPEG-2 stream = adaptive frame skipping • MPEG-4 stream = skipping of macro block coefficients Video Player ClientwithResource Manager and SCHED_EDF Video Server

22. ConclusionsAdaptation Possibilities for Multi-Core Platforms • Application-level adaptation • Application-specific adaptation mechanisms embedded within the application • E.g. Control of FIFO queue lengths in dataflow applications in order to improve latency • Application-level adaptation initiated by the platform • E.g. service level changes in ACTORS RM • Platform-level adaptation • Change speed of cores (DVFS, bandwidth changes) • Change number of cores (DPM, change the number of VPs) • Change the partitioning • Move threads/VPs between cores

23. ACTORS RM Conclusions • Adaptive management made real, but • CPU is the only resource handled • For multicore platforms, but only uni-processor reservations • Future Work • Support for power management • Model-free adaptation • Other types of resources • VR project 2012-2015

24. Demo