An Energyefficient Task Scheduler for Multicore Platforms with

An Energy-efficient Task Scheduler for Multi-core Platforms with per-core DVFS Based on Task Characteristics Ching-Chi Lin, You-Cheng Syu, Chao-Jui Chang, Jan-Jan Wu, Pangfeng Liu, Po-Wen Cheng and Wei-Te Hsu

Introduction Green computing is imperative Increasing of computers Increasing of energy cost Increasing of Carbon emissions

Motivation �Main technologies to improve energy effective ◦ Hardware level: Low power devices ◦ System level: Power-management mechanisms in different levels ◦ Application level: Consolidate with virtualization � Power-management To Shutdown unused mechanisms component or circuit ◦ Circuit level: Clock-gating ◦ System level: DPM ◦ Processor level: DVFS/DVS, C-state

Task Execution Modes • Batch Mode – Batches of jobs • Online Mode – Different time constraints – Interactive and non-interactive tasks – e. g. online judging system

Contributions • Task scheduling strategy that solves three important issues simultaneously: – assignment of tasks to CPU cores – execution order of tasks – CPU processing rate for the execution of each task • Task model, CPU processing rate model, energy consumption model, and cost function. • Workload Based Greedy (WBG) for execution of tasks in the batch mode • Least Marginal Cost (LMC) a heuristic algorithm for executing tasks in the online mode, LMC assigns interactive and non-interactive tasks to cores.

MODELS • Task Model – jk = (Lk, Ak, Dk) – where Lk is the number of CPU cycles required to complete jk, Ak is the arrival time of jk, and Dk is the deadline of jk. If jk has a specific deadline, Dk > Ak ≥ 0 • Processing Rate – Let P = {p 1, p 2, p 3, . . . } be a non-empty set of discrete processing rates a core can utilize based on the hardware, with 0 < p 1 <p 2 < p 3 <. . . < p. – We use p from set P to denote the processing rate of a task j. |P| jk • Energy Consumption k – For a task jk, let ek is energy consumption; tk the execution time; and pjk be the processing rate. – We define E(p) and T (p) as the energy and the time required to execute one cycle with processing rate p on a CPU core

TASK SCHEDULING IN THE BATCH MODE • Tasks with Deadlines / Deadline-Single. Core • Partition problem: let A={a 1, …, an} is set of +ve integers. – Theorem: Deadline-Single. Core is NP Complete. Proof: n tasks j 1, …, jn ; no. of cycles needed for first n task is Li=ai S=a 1+, …, +an: is total no. of cycles for finishing n tasks. T(pl)=2, T(ph)=1, E(ph)=4, E(pl)=1 ; E = T 2 Time constraint is 1. 5 S and energy Constraint is 2. 5 S, deadline is 1. 5 S. • No. of tasks whose sum is at least S/2 to complete in 1. 5 S time and 2. 5 S energy. • • •

Tasks without Deadlines on a Single Core Platform • Cost Function must consider both the energy consumption and the execution time. – Energy Cost: Ck, e = Re. Lk. E(pjk ) – Temporal Cost: Ck is cost of task jk And C is total cost for all tasks

Tasks without Deadlines on a Single Core Platform Amount of delay that a task causes for other tasks

Dominating Position Set/Range • Dp is “dominating position set” of p

Scheduling Tasks without Deadlines on Multi-core Platforms • Scheduling tasks – Homogeneous multi-core systems • Same energy consumption and time consumption function • Round-Robin techniques to assign tasks – Heterogeneous multi-core systems • Different energy consumption and time consumption function • Tasks are assigned in Greedy manner

TASK SCHEDULING IN THE ONLINE MODE • For e. g. Online judging system • Interactive Tasks and Non-interactive Tasks • System can be Homogeneous multi-core or Heterogeneous multi-core • Interactive task higher priority then non-inter: Marginal Cost

Dynamic Task Insertion and Deletion

COCA: Computation Offload to Clouds using AOP Hsing-Yu Chen, Yue-Hsun Lin, and Chen-Mou Cheng

Introduction • Computation Offload – Not Mobile cloud • AOP Approach – COCA works in source level • vs. Binary level approach – In binary level approach, the offload can be made transparent to the application programmers – But the benefits of this become less important in cloud computing

Background • Aspect-Oriented Programming – Increase Modularity by allowing the separation of cross-cutting concerns – Entails breaking down program logic into distinct part

Background • Aspect. J – Allows programmers to define “aspects” • Aspect provides pointcuts and advices for specific functions – Corresponding advices – main AOP used in COCA • before, after, around • Aspect. J for Android – No official support for Android yet – Major changes • Alter the compilation phase of Android Java compiler to Aspect. J • Dynamic Loading for Java Classes – Complied java bytecode(. class) can be loaded and run on a JVM dynamically in runtime

Design of COCA

Profile Stage 1. Mark all pure functions 2. Evaluates the processing time and required memory foot print for each function – – – Result of profiling is summarized in a report Allows evaluation in an emulated environment Allows automate the selection process by integrating COCA with existing program partitioning schemes

Build Stage 1. Divide the original Java source code into ‘to offload’ and ‘not to offload’ – Programmer can selects the target function to offload • It selects the dependent classes 2. Translate the code into Aspect. J code – Filtered Java classes are complied to JVM bytecode – Results • • Jar file for cloud server Apk installation file for Android

Register stage • Assumption – The user already has an account on an existing cloud service (Amazon EC 2) • Process – Run the COCA server daemon in the cloud – Upload the compiled bytecode in jar files to the cloud • Authenticates and loads the clases from the jar file via the dynamic loading

Running 1. Launch the corresponding program 2. COCA requests computation offload 5. Send the result back to smart phone 3. Server retrieve the related classes from the database, load the target classes 4. Perform computation by calling appropriate functions

Experimental Evaluation • Overhead of Aspect. J on Android – Target Device – HTC Tattoo smart phone • Qualcomm MSM 7225 (528 Mhz) – First approach – Comparing the latency of function calls with/without Aspect. J • Before/after advice – 195 ns per call • Around advice – 290 ns per call – Second approach – Android sample application “Amazed” – The overhead brought by Aspect J is negligible

Experimental Evaluation • Real-world Android Chess Game case – AI Capability Enhancement

Experimental Evaluation • Communication Cost • 3 G network : 120/509 kbps (Up/Down) • Transmitted data : 30 KB • COCA should work very well on current Wi-Fi network

Experimental Evaluation • Energy Saving – Using Monsoon power monitor – Experiment on Honzovy achy AI computation • 56% energy reduction

Discussions • Arguments for Working at source level – Additional Overhead • No additional overhead for developer – If he codes in AOP…… • Users – Need to install patched VM – Modularized source code • Developer can simply isolate the design from mobile side and cloud side • Maintenance much easier

Discussions • Pure vs. Non-pure Functions – Non-pure functions • Tend to access global variables, including primitive variable • Static object calls – Synchronize the function with remote object • Serializing – severe cost

Discussions • Potential Application – 3 D image rendering 3 D Games on mobile • Related solutions – NVIDIA Reality. Server – OTOY’s streaming platform – Amazon EC 2 - En. Fuzion

Related works