Control Aspects in Adaptive Multicore CPU Management

Karl-Erik Årzén Dept of Automatic Control Lund University Based on joint work with Vanessa Romero Segovia, Stefan Schorr, Gerhard Fohler, Mikael Kralmark, Johan Eker and several others from the ACTORS project

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, Scuola Superiore Sant’Anna di Pisa, EPFL, AKAtech, Evidence Media applications (soft real-time) for smart phones Control applications

ACTORS: Key Ingredients

1. Data-Flow Programming – CAL Actor Language 2. Feedback-Based Resource Management – Control how much CPU resources that are allocated to different applications based on feedback from resource utilization and achieved QoS

ACTORS: Key Ingredients

3. Reservation-Based CPU Scheduling

10 %

Virtual processors (VPs)

20 %

• Periodic Bandwidth Servers • Constant Bandwidth Server Budget

45 % 25 %

– • • • • SCHED_EDF Partitioned multi-core EDF scheduler Hard CBS reservations Each reservation may contain several threads Period Hierarchical scheduler with SCHED_EDF tasks executing on a higher level than ordinary Linux tasks 4. Multicore Linux Platforms – ARM 11, x86

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

Overview

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

Static Information

From applications to RM at registration: Service Level Table

Service Level QoS BW Requirement BW distribution Timing Granularity

0 1 2 100 75 40 240 180 120 - Thread IDs and how they should be grouped From system administrator to RM at startup: Application Importance

Appl.

Importance

Appl 1 Appl 2 Appl 3 Default 10 20 100 10 60-60-60-60 45-45-45-45 30-30-30-30 20 ms 20 ms 20 ms

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

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

Outputs

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

Control Logic

Partition 1

Dataflow Analysis

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

CAL Run-Time System

IO

Thread Thread VP Core 2 VP • • • • Core 1 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

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

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

Resource Manager Tasks

• Bandwidth adaptation – Adjust the servers bandwidth dynamically based on measured resource usage and obtained happiness EP SP EP – If the application is unhappy the bandwidth is increased until the application is happy Changes what is meant by sufficiently close based on EP: Changes the AB so that the UB lies sufficiently close:

16

Resource Manager Tasks

Multiple bandwidth adaptation strategies Strategy 1: A VP may never consume more bandwidth than what was originally assigned to it BW controller may reduce the BW if not used

May only be reused by ordinary Linux tasks

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

May also be reused by SCHED_EDF tasks

All applications are always guaranteed to obtain their originally assigned values (can never be compressed beyond that)

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 17

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 decoder to the camera to reduce the frame rate and/or resolution Shown in demo

MPEG-4 Video Decoding Demonstrator

Application unhappy More important application started. SL decreased Application terminated. SL increased again

Feedback Control Demonstrator

• • • • • Industrial robot balancing an inverted pendulum • Controller in CAL Ball and Beam Processes • Controller in CAL MPEG-4 Video Decoder Service level changes correspond changes in sampling period Video available if someone is interested during the break

Video Quality Adaptation Demonstrator

Video Server Video Player Client with Resource Manager and SCHED_EDF • • • 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

Conclusions

Adaptation 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

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

Demo