|
|
|
@ -79,16 +79,23 @@ We find similar behavior in our other case study apps.
|
|
|
|
|
|
|
|
|
|
\subsection{Application Cold-Start}
|
|
|
|
|
Many apps require significant compute at launch to initialize themselves.
|
|
|
|
|
While facebook does not, one of the other apps in our study, Spotify, takes 2s to coldstart.
|
|
|
|
|
While facebook does not, one of the other apps in our study, Spotify, takes notably longer.
|
|
|
|
|
During this time, the user is waiting on the app to become responsive.
|
|
|
|
|
It makes sense under such circumstances to run the CPUs at a higher speed to enhance user experience.
|
|
|
|
|
As we will discuss further in section \ref{subsec:signal_perf_needs}, the system already boosts the CPU to 100\% speed upon app launch for $\sim$.5s.
|
|
|
|
|
Figure \ref{fig:coldstart_time_spot}, however, shows this is insufficient.
|
|
|
|
|
The right-side graph shows that the app does not become fully responsive (Time to Fully Drawn, or TTFD) until $\sim$2s.
|
|
|
|
|
|
|
|
|
|
Figure \ref{fig:coldstart_time_spot} shows the results of a study to examine the benefits and costs of doing this.
|
|
|
|
|
Bear in mind that the unmodified system already uses the .. to provide a minimal $\sim$.5s boost to CPU speed.
|
|
|
|
|
Ironically, the largest benefit comes in energy saved...
|
|
|
|
|
The graph depicts the latency of initial display (when the app screen appears) and TTFD under 4 CPU policies: the default \schedutil, a fixed 70\% CPU speed, and the same 2 but with the CPU frequency set to 100\% from userspace.
|
|
|
|
|
The vertical axes depict energy consumed; the inner boxes represent detail zooms of the larger plots.
|
|
|
|
|
Unsurprisingly, the fixed 70\% policy offers worst performance on both metrics.
|
|
|
|
|
The second worst is had by the unmodified default policy -- which also offers the worst energy performance.
|
|
|
|
|
The best performance comes from a fixed 70\% frequency with a 2s boost.
|
|
|
|
|
Likely, the \schedutil with a 2s boost policy harms itself with slow ramp-up.
|
|
|
|
|
|
|
|
|
|
This shows that the existing CPU policy degrades user experience through poor latency.
|
|
|
|
|
Instead, a general-purpose 70\% speed combined with as-needed (and properly timed) frequency boosts offers both better performance (user responsiveness) and energy usage.
|
|
|
|
|
|
|
|
|
|
\todo{Add a section here discussing cold-start launches}
|
|
|
|
|
|
|
|
|
|
\subsection{Adaptive Apps}
|
|
|
|
|
\label{sec:adaptiveApps}
|
|
|
|
|