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

edits

master
Lukasz Ziarek 2023-08-25 23:14:28 -04:00
parent c70050d3ba
commit 1915ce46e3
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
sections/introduction.tex
View File

@ -3,7 +3,7 @@
\begin{figure}
\centering
\includegraphics[width=.95\linewidth]{figures/graph_missed_opportunities.pdf}
\includegraphics[width=.90\linewidth]{figures/graph_missed_opportunities.pdf}
\bfcaption{A trace of \schedutil's cpu frequency selections given in blue. The dotted red line shows a energy/latency optimal frequency choice ($\fenergy$).}
\label{fig:missed_opportunities}
\end{figure}
@ -34,20 +34,20 @@ We identify flaws in the premises, and propose a new, simpler governor that has
Our fundamental insight, also observed by prior work~\cite{vogeleer2013energy, nuessle2019benchmarking}, is that there exists an energy-optimal frequency for each device (call it $\fenergy$).
We argue that
(i)~past CPU usage is not a meaningful signal for identifying the rare cases when speeds below $\fenergy$ are appropriate,
(i)~past CPU usage is not a meaningful for identifying the rare cases when speeds below $\fenergy$ are appropriate,
(ii)~speeds above $\fenergy$ are useful only in specific situations, often known in advance by user-space.
\Cref{fig:missed_opportunities} illustrates the potential for improvement;
(i)~\schedutil has a ramp-up period (first grey box) where the CPU is operating at speeds that sacrifice both energy and performance, and
(ii)~\schedutil continues ramping up the frequency (second grey box) paying significant energy costs for often negligible visible benefits.
We propose a series of changes to \schedutil, ultimately converging on a radical proposal: Default the CPU's frequency to its $\fenergy$, switching to faster speeds based only on (already existent) signals from user-space.
We propose a series of changes to \schedutil, ultimately converging on a radical proposal: default the CPU's frequency to its $\fenergy$, switching to faster speeds based only on (already existent) signals from user-space.
Based on the simplicity of this approach, we call it the \systemname governor.
Through experiments, we show that \systemname simultaneously improves performance, as well as energy usage:
For example, a typical 25s Facebook app interaction run with \systemname consumes 11\% less energy and causes 17\% fewer UI screendrops than when run with default settings.
We also explore a less radical proposal: \schedutil limited to selecting frequencies at or above $\fenergy$; We show that even with this minor change, significant gains are possible.
Through experiments, we show that \systemname simultaneously improves performance and energy usage.
For example, a typical 25s Facebook run with \systemname consumes 11\% less energy and causes 17\% fewer UI screendrops than when run with default settings.
We also explore a less radical proposal: \schedutil limited to selecting frequencies at or above $\fenergy$. We show that even with this minor change, significant gains are possible.
We run our experiments on Google Pixel 2 devices with Android AOSP, evaluating \systemname against the system default and several other policies, using microbenchmarks and popular apps.
These are representative of common platforms and uses in the real world.
%We run our experiments on Google Pixel 2 devices with Android AOSP, evaluating \systemname against the system default and several other policies, using microbenchmarks and popular apps.
%These are representative of common platforms and uses in the real world.
This paper is organized as follows:
(i) We review background and related work in \Cref{sec:related}.