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

Edits

master
Lukasz Ziarek 2023-08-25 15:01:01 -04:00
parent fe5ad300ba
commit 04853a12a6
1 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
sections/unjustified.tex
View File

@ -25,14 +25,14 @@
%\bfcaption{Big CPUs}
%\end{subfigure}
%
\bfcaption{Runtime and energy for a fixed compute workload per CPU, varying governor policy and number of CPUs. Energy measurements are taken over a fixed 75s period that includes the workload. (Average of 5 runs, 90\% confidence)}
\bfcaption{Runtime and energy for a fixed compute workload per CPU, varying governor policy and CPUs. Energy measurements are taken over a fixed 75s period that includes the workload. (Average of 5 runs, 90\% confidence)}
\label{fig:u_micro}
\end{figure*}
As CPU frequency increases, the energy per unit of \emph{time} required to operate the CPU grows.
As CPU frequency increases, the energy per unit of \emph{time} used by the CPU grows.
This is the fundamental premise behind governor design.
However, as illustrated in \Cref{fig:item_energy_cost}, an idling mobile CPU consumes only negligible energy.
Given this, the more useful metric to us is the energy per unit of \emph{work}.
However, as illustrated in \Cref{fig:item_energy_cost}, an idling mobile CPU consumes negligible energy.
Given this, the more useful metric is the energy per unit of \emph{work}.
As we argue in this section, the relationship between frequency and cost-per-cpu cycle is convex, driving our first claim:
\claim{
@ -43,8 +43,7 @@ As we argue in this section, the relationship between frequency and cost-per-cpu
For this experiment, we prepared a deterministic, cpu-bound arithmetic workload.
We ran the workload with a series of CPU policies that fix the CPU to a particular speed, as well as the default \schedutil governor for comparison.
We also vary the number of loads from 1-4, with each pinned to a separate CPU within a CPU cluster, and whether the loads are run on either big or little CPUs.
We also remind the reader that regardless of governor policy, idle CPU cores are put into a low-power C-state.
Regardless of governor policy, idle CPU cores are put into a low-power C-state.
On the x-axis, we measure the total time to complete the fixed amount of work.
On the y-axis, we measured energy over a fixed period of 75s;
@ -59,11 +58,11 @@ Compared to frequencies below this point, it is more efficient to run the core a
\subsection{$\fenergy$ in General}
Previous works \cite{vogeleer2013energy, Liang2011AnEC, nuessle2019benchmarking} have suggested that, for a given workload, there is an energy-optimal frequency.
The Linux kernel maintainers themselves observe that, absent compelling corner cases such as thermal throttling, \textit{there is no reason to set the CPU to a non-idle speed below $\fenergy$}\cite{energy-aware-schedutil}.
The Linux kernel maintainers observe that, absent compelling corner cases such as thermal throttling, \textit{there is no reason to set the CPU to a non-idle speed below $\fenergy$}\cite{energy-aware-schedutil}.
While the exact optimal frequency depends on the specific CPU and core type, this $\fenergy$ is not, generally, the slowest frequency available.
We observe that frequencies slower than $\fenergy$ are useful for situations where it is not possible to fully saturate the CPU, but \emph{idling is not an option};
For example, in memory-bound workloads (i.e., with frequent CPU stalls resulting from cache misses), workloads with high spin-lock contention, and similar busy-waiting scenarios, it can be beneficial to reduce the CPU frequency to minimize the number of unused CPU cycles\footnote{
We observe that frequencies slower than $\fenergy$ are useful for situations where it is not possible to fully saturate the CPU, but \emph{idling is not an option}:
in memory-bound workloads (i.e., with frequent CPU stalls resulting from cache misses), workloads with high spin-lock contention, and similar busy-waiting scenarios, it can be beneficial to reduce the CPU frequency to minimize the number of unused CPU cycles\footnote{
We note that we did not encounter any significant busy-waiting across all of the apps that we tested.
}.