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

edits

master
carlnues@buffalo.edu 2023-08-25 02:09:01 -04:00
parent 9692f7342e
commit c5f28ad1bd
1 changed files with 14 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
sections/evaluation.tex
View File

@ -43,6 +43,13 @@
\label{fig:nonidle_spot}
\end{figure*}
\begin{figure*}
\centering
\includegraphics[width=\linewidth]{figures/graph_idlejank_heavyload.pdf}
\bfcaption{The effect of additional background loads on user experience, for given CPU policies}
\label{fig:idlejank}
\end{figure*}
We now evaluate the \systemname and truncated \schedutil governors, by comparing their performance on a range of representative workloads the default Android \schedutil governor.
Concretely, we evaluate the claims that on normal workloads:
@ -77,7 +84,8 @@ The \textbf{Facebook} workload was described in \Cref{sec:low-speed-in-practice}
The \textbf{YouTube} workload starts the app, and searches a popular video by its name.
The app selects the first hit, starts the video, and waits for 30 seconds.
The specific video was selected to get a predictable high rate of being served random motion video ads at the start.
The \textbf{Spotify} workload... \todo{Fill in details}.
The \textbf{Spotify} workload...
\todo{Fill in details}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Screen Jank}
@ -111,20 +119,15 @@ In summary, the improved performance of both truncated \schedutil and \systemnam
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Jank Under High-Load}
\begin{figure}
\centering
\includegraphics[width=\linewidth]{figures/graph_idlejank.png}
\bfcaption{The effect of additional background loads on user experience, for given CPU policies \fixme{REDO -- AWFUL GRAPH}}
\label{fig:idlejank}
\end{figure}
We next explore the level of additional load required to degrade the user experience.
For this experiment, we run the facebook workload in the presence of background tasks.
These background tasks generate additional background load by performing simple arithmetic with periodically injected sleeps at varying intervals.
We pin one load-producing task to each of the 8 CPU cores.
%We collect non-idle time through sysfs and framedrop rate through Android GFX as before.
%We pin one load-producing task to each of the 8 CPU cores.
\Cref{fig:idlejank} illustrates the effect of the added CPU load on the measured jank.
The x-axis shows the average load across all 8 CPU cores (based on the injected sleeps), and the frame-drop rate is shown on the y-axis.
Note that a smaller sleep interval equates to a higher load.
The leftmost part of the graph, with the smallest circles (representing a normal interaction, with no additional background load) shows that a fixed speed of 70\% or greater produces a measured screen drop rate that is essentially idential with that of the system default.
@ -145,7 +148,8 @@ In actual usage, a user would likely never encounter this level of background us
We next review our findings from \Cref{sec:adaptiveApps}, that typical apps increase their offered load as CPU capacity increases.
\Cref{fig:nonidle_fb,fig:nonidle_yt,fig:nonidle_spot} illustrate the fraction of the of time the CPU spends doing work in each workload as CPU frequency increases.
Recall that, assuming the amount of work stays constant in a fixed-duration workload, the time spent non-idle would show an inverse-linear relationship with the CPU frequency.
As with Facebook, the Youtube workload shows a much flatter relationship, particularly on the big cores. \todo{Discuss Spotify}
As with Facebook, the Youtube workload shows a much flatter relationship, particularly on the big cores.
\todo{Discuss Spotify}