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

Merge branch 'master' of https://git.odin.cse.buffalo.edu/carlnues/paper-KeepItSimple

master
carlnues@buffalo.edu 2023-08-25 22:04:44 -04:00
parent c1d57610e9 94b99c0eea
commit 111f488952
3 changed files with 16 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
sections/evaluation.tex
View File

@ -51,11 +51,10 @@
\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.
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:
(i) truncated \schedutil achieves better performance than regular \schedutil without significantly increasing energy consumption, and
(ii) \systemname achieves better energy consumption than \schedutil, without significantly increasing screen jank.
We further conduct several experiments to confirm our observations from \Cref{sec:wasted}, namely that:
(iii) the adaptive app pattern is not unique to facebook,
(iv) apps spend significant time below $\fenergy$.
@ -67,15 +66,13 @@ We further conduct several experiments to confirm our observations from \Cref{se
\paragraph{Evaluation platform}
Our results were obtained using Google Pixel 2 devices running Android AOSP 10 with 4 GB RAM and 128 GB SSD storage and the Snapdragon 835 chipset~\cite{snapdragon-835}.
Standalone microbenchmarks were implemented in C, while end-to-end macrobenchmarks were performed using the Android UI Automator testing framework to perform scripted simulated interactions with real-world apps~\cite{uiautomator}.
Standalone microbenchmarks were implemented in C, while end-to-end macrobenchmarks were performed using the Android UI Automator testing framework to perform scripted, simulated interactions with real-world apps~\cite{uiautomator}.
One of the phones was modified to obtain energy measurements using the Monsoon HVPM power meter~\cite{monsoon}.
Our evaluation system consists of a pair of shell scripts running on the phone and an external monitor, respectively.
The external script sleeps for 10s to ensure quiescence and prevent inter-trial artifacts, and initializes both the Monsoon meter and the on-phone script.
The on-phone script sleeps for 20s to ensure that the Monsoon meter is capturing data, sets the desired governor policy, and starts the experiment.
When the experiment concludes, the on-phone script sleeps for a further 10s to ensure that the Monsoon meter captures the full trace, and notifies the external script that the experiment has concluded.
The external script concludes by retrieving relevant artifacts from the phone, excluding data transfer from any energy or performance measurements.
%When the experiment concludes, the on-phone script sleeps for a further 10s to ensure that the Monsoon meter captures the full trace, and notifies the external script that the experiment has concluded.
%The external script concludes by retrieving relevant artifacts from the phone, excluding data transfer from any energy or performance measurements.
We collected information on CPU speed and idlestate from both the Linux \texttt{ftrace} framework and from \texttt{sysfs}, and on CPU cycles from the \texttt{perf\_event\_open} syscall~\cite{perf-event}.
We also used \texttt{ftrace} to log testing parameter and state.
Information on screen performance including framedrops came from the Android \texttt{dumpsys gfxinfo} service.
@ -84,20 +81,24 @@ 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 discused in subsection \ref{subsec:signal_perf_needs},
(ii) a truncated \schedutil implemented by lower-bounding the CPU using the existing API discussed in subsection \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
(vi) the \texttt{performance} governor.
<<<<<<< HEAD
We include (ii) and (iii) to compare the general performance of the truncated \schedutil and a general-case $\sim$70\% speed policies when implemented under the existing API with that when implemented using \systemname.
=======
We include (ii) and (iii) to compare the general performance of the truncated \schedutil and a common-case $\sim$70\% speed policies when implemented under the existing API with the equivalents implemented using \systemname.
>>>>>>> 5a54aecac642577b25bdd5ae50dbe55c0103d47a
Under default Linux, a specific CPU speed requested gets implemented as the next-highest speed in a preset series of supported speeds in \texttt{scaling\_available\_frequencies} in \texttt{sysfs}.
We follow this behavior with our system.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{Workloads}
We consider four separate workloads, the first 3 involving indiviual apps: (i) Facebook, (ii) YouTube, and (iii) Spotify.
We consider four separate workloads, the first 3 involving individual apps: (i) Facebook, (ii) YouTube, and (iii) Spotify.
The fourth (iv) workload combines the Facebook and Spotify loads.
These were designed to mimic common user phone interactions.
%These were designed to mimic common user phone interactions.
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.
@ -115,9 +116,10 @@ These workloads address evaluation claim (iii).
These graphs address the performance aspect of claims (i) and (ii).
On all workloads, \systemname and truncated \schedutil offer nearly identical or notably better performance than regular \schedutil.
The Facebook load under \systemname costs an additional .3\%, or $\sim$.2 frames per second at 60fps.
We argue this does not noticably affect user experience and is more than acceptable given the greater than 10\% energy savings.
We argue this does not noticeably affect user experience and is more than acceptable given the greater than 10\% energy savings.
The results of the truncated \schedutil policies and of fixedspeed 70\% similarly offer significant energy savings at small to zero cost.
Youtube shows a clear performance win for \systemname compared to the default.
The truncated \schedutil policies and fixed speed 70\% policy also offer improved sreendrop rates.
Performance under \systemname for both the Spotify and the Combined workloads, like that for Facebook, costs .3\% fps compared to the default -- a cost we again argue is both very minimal and acceptable.
@ -141,8 +143,7 @@ In summary, the improved performance of both truncated \schedutil and \systemnam
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Jank Under High-Load}
We next explore the level of additional load required to degrade the user experience.
%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 collect non-idle time through sysfs and framedrop rate through Android GFX as before.

2
sections/unjustified.tex
View File

@ -12,7 +12,7 @@
\begin{figure*}
\centering
\includegraphics[width=.90\linewidth]{figures/graph_u_fixedlen_multicore.pdf}
\includegraphics[width=.80\linewidth]{figures/graph_u_fixedlen_multicore.pdf}
%
%\begin{subfigure}{0.45\textwidth}
%\centering

2
sections/wasted.tex
View File

@ -10,7 +10,7 @@
\begin{figure*}
\centering
\includegraphics[width=.90\linewidth]{figures/graph_energy_perf_coldstart_spot.pdf}
\includegraphics[width=.80\linewidth]{figures/graph_energy_perf_coldstart_spot.pdf}
\bfcaption{Energy and latency of coldstarting Spotify under different policies (5 runs, 90\% confidence)}
\label{fig:coldstart_time_spot}
\end{figure*}