57 lines
4.1 KiB
TeX
57 lines
4.1 KiB
TeX
% -*- root: ../main.tex -*-
|
|
%!TEX root=../main.tex
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=.8\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}
|
|
|
|
\begin{figure}
|
|
\begin{tabular}{l|c}
|
|
System Configuration & Energy Usage (mA) \\ \hline
|
|
System idle (screen off) & 10 \\
|
|
Lock screen on; idle & 100 \\
|
|
Launch screen on; idle & 130 \\
|
|
1 CPU saturated; screen off & 310 \\
|
|
2 CPUs saturated; screen off & 560 \\
|
|
\end{tabular}
|
|
\bfcaption{Energy usage on a Pixel 2}
|
|
\label{fig:item_energy_cost}
|
|
\end{figure}
|
|
|
|
CPUs consume considerable energy on mobile phones.
|
|
As Table \ref{fig:item_energy_cost} shows, a single (big) CPU core on a Pixel 2, running at full speed with the screen off, consumes almost three times the energy of the display, and a second core running at full speed almost doubles that.
|
|
On typical mobile phones, these high costs are mitigated by running the CPU at a slower speed (frequency) to save energy.
|
|
The policies that govern this speed selection, called governors, must balance providing computation resources when needed, and reducing resources to save energy when not.
|
|
|
|
Most popular recent and current Android (resp., Linux) governors, including the \texttt{ondemand}, \texttt{interactive}, and the \texttt{conservative} policies, as well as the current Android system default, \schedutil, use a proportion of recent past CPU usage as a guide to set future speeds.
|
|
In this paper, we explore several premises on which the designs of these governors are based.
|
|
We identify flaws in the premises, and propose a new, simpler governor that has better latency and power consumption than \schedutil.
|
|
|
|
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 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 (left grey box) where the CPU is operating at speeds that sacrifice both energy and performance, and
|
|
(ii)~\schedutil continues ramping up the frequency (right 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.
|
|
Based on the simplicity of this approach, we call it the \systemname governor.
|
|
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.
|
|
|
|
This paper is organized as follows:
|
|
(i) We review background and related work in \Cref{sec:related}.
|
|
(ii) In \Cref{sec:unjustified}, we confirm our hypothesis that $\fenergy$ exists and demonstrate that speeds below $\fenergy$ are usually unjustified.
|
|
(iii) In \Cref{sec:wasted}, we explore the remainder of the design space through a series of micro-benchmarks that motivate \systemname.
|
|
(iv) In \Cref{sec:design}, we tie together our claims from the preceding sections in the design of a series of governors along the gradient from \schedutil to \systemname.
|
|
(v) Finally, we evaluate these proposed governors in \Cref{sec:evaluation}.
|
|
|