Web Applications Yuhao Zhu, Matthew Halpern, Vijay Janapa Reddi Department of Electrical and Computer Engineering The University of Texas at Austin HPCA — Feb. 9th, 2015
feel the system is reacting responsively [Miller 1968; Card et al. 1991] ▸64% of mobile users will not revisit a slow Web app [Source: Akamai] ▸Amazon found every 100 ms of latency costs them 1% in sales per year [Source: Amazon]
user QoS expectation ▹ Develop a runtime system that leverages the large scheduling space of heterogeneous CPUs 6 Executive Summary Event-level Characterization
user QoS expectation ▹ Develop a runtime system that leverages the large scheduling space of heterogeneous CPUs Runtime Mechanics to Exploit Latency Slack 6 Executive Summary Event-level Characterization
user QoS expectation ▹ Develop a runtime system that leverages the large scheduling space of heterogeneous CPUs Runtime Mechanics to Exploit Latency Slack Heterogeneous Resource Utilization 6 Executive Summary Event-level Characterization
user QoS expectation ▹ Develop a runtime system that leverages the large scheduling space of heterogeneous CPUs Runtime Mechanics to Exploit Latency Slack Heterogeneous Resource Utilization 6 Executive Summary Event-level Characterization
Small Slack click Unusable QoS ▸ Wide distribution of event latencies. Events exhibit different slacks. ▹ How to exploit different slacks for different events? 150 100 50 0 Event Latency (ms) Events
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Memory Operation CPU Operation Tmemory Ndependent f Event Latency Xie, et al., Compile-Time Dynamic Voltage Scaling Settings: Opportunities and Limits, PLDI’03
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Memory Operation CPU Operation Tmemory Ndependent f Event Latency Xie, et al., Compile-Time Dynamic Voltage Scaling Settings: Opportunities and Limits, PLDI’03 Event Latency =
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Memory Operation CPU Operation Tmemory Ndependent f Event Latency Xie, et al., Compile-Time Dynamic Voltage Scaling Settings: Opportunities and Limits, PLDI’03 Event Latency = Tmemory +
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Memory Operation CPU Operation Tmemory Ndependent f Event Latency Xie, et al., Compile-Time Dynamic Voltage Scaling Settings: Opportunities and Limits, PLDI’03 Event Latency = Tmemory + Ndependent / f
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Memory Operation CPU Operation Tmemory Ndependent f Event Latency Xie, et al., Compile-Time Dynamic Voltage Scaling Settings: Opportunities and Limits, PLDI’03 Event Latency = Tmemory + Ndependent / f
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Event Latency = Tmemory + Ndependent / f Event Latency Frequency
<core, freq> Feedback How the Model Constructor Works 12 ▸ Goal: Estimate the event latency under each <core, freq> config Event Latency = Tmemory + Ndependent / f Event Latency Frequency
<core, freq> How the Detector Works 13 ▸ Goal: Find the QoS target for each event CamanJS Pdf.js Crypto Zlib Paper.js Ember.js GWT Backbone jQuery sina google ebay Doom Rain 10-4 104 106 100 Feedback
<core, freq> How the Detector Works 13 ▸ Goal: Find the QoS target for each event CamanJS Pdf.js Crypto Zlib Paper.js Ember.js GWT Backbone jQuery sina google ebay Doom Rain 10-4 104 106 100 CamanJS Pdf.js Crypto Zlib Paper.js Ember.js GWT Backbone jQuery sina google ebay Doom Rain 10-4 104 106 100 Event Latency (s) Event Intensity (evt/s) NA Feedback
<core, freq> How the Detector Works 13 ▸ Goal: Find the QoS target for each event CamanJS Pdf.js Crypto Zlib Paper.js Ember.js GWT Backbone jQuery sina google ebay Doom Rain 10-4 104 106 100 CamanJS Pdf.js Crypto Zlib Paper.js Ember.js GWT Backbone jQuery sina google ebay Doom Rain 10-4 104 106 100 Event Latency (s) Event Intensity (evt/s) NA Feedback [1, 10] s [50, 100] ms [60, 30] fps
<core, freq> Feedback How the QoS Monitor Works 14 ▸ Goal: Predict the <core, frequency> for the next event Predicted Latency Frequency Big Core Little Core
<core, freq> Feedback How the QoS Monitor Works 14 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core
<core, freq> Feedback How the QoS Monitor Works 14 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core
<core, freq> Feedback How the QoS Monitor Works 14 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core ▸ Scheduling overhead (~120 us): ▹ Core migration ▹ Frequency switching
<core, freq> Feedback How the QoS Monitor Works 15 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core
<core, freq> Feedback How the QoS Monitor Works 15 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core
<core, freq> Feedback How the QoS Monitor Works 15 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core ▸ Fine-tune the execution upon over- prediction or under-prediction
<core, freq> Feedback How the QoS Monitor Works 15 ▸ Goal: Predict the <core, frequency> for the next event QoS Target Predicted Latency Frequency Big Core Little Core ▸ Fine-tune the execution upon over- prediction or under-prediction ▸ Recalibrate if it mispredicts too often
Standard to guarantee responsiveness ▹ Minimal energy (Energy) — Minimize energy consumption ▹ Interactive governor (Interactive) — Android default ▹ On-demand governor (Ondemand) 17 PH Imperceptible 0 PI PU PL QoSU QoSI Tolerable Unusable -ESU ESI EST Quality-of-Service (QoS) Energy Savings (ES) Performance Degradation ▸ Scheduling Scenarios ▹ Scheduling for imperceptibility ▹ Scheduling for tolerability
Standard to guarantee responsiveness ▹ Minimal energy (Energy) — Minimize energy consumption ▹ Interactive governor (Interactive) — Android default ▹ On-demand governor (Ondemand) 17 PH Imperceptible 0 PI PU PL QoSU QoSI Tolerable Unusable -ESU ESI EST Quality-of-Service (QoS) Energy Savings (ES) Performance Degradation ▸ Scheduling Scenarios ▹ Scheduling for imperceptibility ▹ Scheduling for tolerability
PI PU PL QoSU QoSI Tolerable Unusable -ESU ESI EST Quality-of-Service (QoS) Energy Savings (ES) Performance Degradation ▸ Need a systematic way of understanding and QoS-energy trade-offs. To that end we advocate eQoS to strike a balance between user satisfaction and energy reduction ▸ User interactivity and human perceptibility are important because it has economic ramifications and impacts user device choice, as well as end-user satisfaction
PI PU PL QoSU QoSI Tolerable Unusable -ESU ESI EST Quality-of-Service (QoS) Energy Savings (ES) Performance Degradation ▸ Need a systematic way of understanding and QoS-energy trade-offs. To that end we advocate eQoS to strike a balance between user satisfaction and energy reduction ▸ Develop the event-based scheduling (EBS) mechanism that exploits the fundamental event-driven execution pattern of mobile applications to achieve better eQoS ▸ User interactivity and human perceptibility are important because it has economic ramifications and impacts user device choice, as well as end-user satisfaction Heterogeneous Hardware Event Queue H3 … H2 … H1 Dispatch <Core, Freq> PI, PU Detector QoS Monitor Model Constructor Recalibrate Event-Based Scheduler Event Info Models onkeyup=“H1 () {…}” keyup onchange=“H2 () {…}” change Event execution feedback onclick=“H3 () {…}” click
queeten
reverentgeek
rmw
skipperchong
carmenhchung
keathley
productmarketing
clairelew
thoeni
jcasabona
