An Effective Feedback-Driven Approach for Energy Saving in

Battery Powered System

Student: Duy LeAdvisor: Prof. Dr. Haining Wang

Department of Computer ScienceThe College of William and Mary

• Laptops or netbooks• Varied running applications

Browsers, editing, multimedia, etc

• Runtime varies from 0.5 to 5.5 hours• Not only run on Windows, but Linux• Two challenges of productivity:

Achieving a high energy efficiency

Guaranteeing QoS requirements of applications

Battery-powered (BP) systems

• Previous Work• Feedback QoS based Model – Application Requests– Feedback driven model– FQM Algorithm

• Implementation• Experimentation• Conclusion

Previous Work

• Power-aware systems (Lu-IEEE Trans’02)• Do not aim to guarantee application QoS

• Feedback Control real-time Scheduling (Lu-IEEE Trans’03)• Only applicable for adaptive real-time systems

• Dynamic power management (Minerick-COS’02)• Exploits processor frequency to meet a given energy level

• Homogeneous architecture for power policy (Pettis-IEEE Trans’09)• Does not consider primitive I/Os

• QoSPM of Intel (since Linux kernel 2.6.23)• Only statically maintains application QoS

Application Request

• Represents user I/O requests to system• Associated with application process• Monitors I/O requests interacted with the

system's power management (PM)• Two system objects: networks and filesystems• Two types of interactions: periodic and non-

periodicRQ=(FS/NET, R/W,PE/NPe,CS,DS, Ti, To)

Application behavior• Online interactions

– Initiate data transmission (periodic read/write network)

– Store data to filesystem (aperiodic write filesystems)

• Multipart file transmission

– Multiple connections yield an advantage on saturated links (bandwidth and resilience)

– Periodically read data from networks

– Periodically write data to filesystem

• Online video streaming– Receiving stream media as the first-hand user

– Re-streaming this media as the second-hand user

– Periodically read data from networks

– Periodically write data to networks

Modeling FQM

• Requirements:– QoS based features– Address major challenges of system productivity

• Three steps to be followed to guarantee the model precision [Lu,IEEETrans'05]– Specifying correlated parameters– Describing relationship between two feature groups:

control input and control variables– Designing a steady algorithm

FQM- Feedback QoS based Model•Output

•QoS guarantee and power saved executions of applications

•Input•Control inputs: application requests

•Control variables: feedback utilization modification

•Attributes to process requests: Inter-arrival time, execution time, CPU utilization, utilization ratio, and miss ratio

•FQM includes two sets of components:•Internal components: Source, Manager, Executor, Monitor, and Controller

•External components: Energy References and QoS Policies

FQM - Internal Components

• Source• Known as I/O components of applications• Initiates I/O transactions

• Manager handles two major jobs:• Creating tasks

• Based on delivered application requests• Based on pre-estimated QoS parameters referred from QoS

Policies

• Rescheduling tasks• Based on old and new tasks• Reassigns QoS parameters

FQM – Internal Components

• Executor• Processes all tasks from Manager• Executes task based on QoS requirements

• Monitor• Measures FQM attributes: Actual inter-arrival time and

execution time • Updates these measurements to Controller

• Controller• Computes control variables (CPU utilization, utilization ratio, and

miss ratio)• Delivers corresponding control variables to Manager

FQM – External Components

• QoS Policies• Preserve a list of pre-estimated QoS parameter sets• Classify parameter sets based on I/O buffer and estimated

task time out

• Energy References• Maintain a list of pre-estimated CPU utilization

(read/write/send/recv)• Differentiate based on data size and I/O destination

FQM Algorithm• Monitor control variables (δ,

M, U)• Outer loop:

• Verifies input transactions

• Creates tasks and verifies received feedbacks.

• Inner loop:• Embodies the feedback loop

• Delivers and processes new tasks

• Reassigns QoS parameters for old tasks

Implementation

• External components:• Located at Linux system user level• ER estimates CPU cycles of read/write/send/recv• QP estimates QoS parameters of emulate tasks.• Overhead in looking up data in ER and QP

• Kernel level replica

• High-resolution CPU timer

• Internal components:• Located at Linux system kernel level• Differentiate I/O transactions based on assigned /proc • Use binary search to search data in ER and QP

Experimentation

•Configuration•Dell laptop 1.6 GHz Intel Pentium M, Linux kernel 2.6.29, Ext3 filesystem

•Test cases•Vanilla system•QoSPM-based system•FQM-based system•FQM + QoSPM system

•Setup•Firefox: 50 common websites and keystroke patterns•Caxel: Schedules data transmissions, up to 50 connections, and different file sizes•VLC: RTP stream (Mpeg-1) received and HTTP stream re-streamed

Power Consumption

Average power consumption Consumed power for first 300 s

-FQM noticeably lowers 5% the consumed power than QoSPM-FQM + QoSPM can stabilize consumed power and lower 3% than vanilla system

-Individual apps- QoSPM reduce 3-5%- FQM reduce from 9-15%

-All apps- FQM + QoSPM from 2-10%

-FQM + QoSPM regulate tasks:- Based on QoSPM metrics- Based on FQM’s QoS parameters

Quality of Services

Control variable variation Regulated tasks-Miss ratio:

- Vanilla system: 33%- QoSPM-based system: 29%

-Utilization ratio:- Vanilla system: 81%- QoSPM-based system: 83%

-Priority of most tasks are readjusted: 90% for Firefox, and 84% for Caxel and VLC-FQM reasigns 14% of Caxel’s task in vanilla and 66% in QoSPM based-For Firefox and VLC, the number of QoS reassignments is similar in both systems.

System Performance

CPU cycles to process tasks Incremental overhead

-Major computations occur at Manager, QP and ER-Manger ‘s overhead is 18% in Caxel and 21% in VLC-QP (25%) and ER (47%) overhead depend on its size and searching complexity

-QP and ER consist of 6K elements as baseline-Overhead increase 45% (QP) and 26% (ER) when the size increases 1K elements

Conclusion

• FQM as a feedback-driven model:• Improves BP system’s energy efficiency• Guarantees given QoS requirements

• FQM architecture • Designed as component-based• Implemented at kernel and user levels

• Experimentations• Conducted on real systems• FQM regulates I/O transactions exploiting CPU cycles• Reduced energy + guarantee QoS

Questions !?!?