carlnues
/
paper-KeepItSimple
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

edits (eval) (coldstart discussion)

master
carlnues@buffalo.edu 2023-08-25 23:54:50 -04:00
parent 56c0af6b18
commit bc606139fe
2 changed files with 13 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
sections/evaluation.tex
View File

@ -81,7 +81,7 @@ Information on screen performance including framedrops came from the Android \te
\paragraph{CPU Policies}
We evaluate six different CPU policies under different workloads:
(i) the system default, \schedutil,
(ii) a truncated \schedutil implemented by lower-bounding the CPU using the existing API discussed in subsection \ref{subsec:signal_perf_needs},
(ii) a truncated \schedutil implemented by lower-bounding the CPU using the existing API discussed in section \ref{subsec:signal_perf_needs},
(iii) a fixed 70\% speed using the existing \texttt{userspace} governor,
(iv) a truncated \schedutil implemented with \systemname,
(v) unmodified \systemname, and

19
sections/wasted.tex
View File

@ -79,18 +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.
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.
Bear in mind that the unmodified system already uses the .. to provide a minimal $\sim$.5s boost to CPU speed.
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.
Ironically, the largest benefit comes in energy saved...
\todo{Add a section here discussing cold-start launches}
\subsection{Adaptive Apps}
\label{sec:adaptiveApps}