edits
parent
f58d9a0fbc
commit
fe5ad300ba
|
@ -7,9 +7,8 @@ Historically, systems have addressed the competing goals of energy and latency o
|
|||
On modern systems, CPUs typically consist of multiple cores, often of different types, that run at different speeds (known as P-states) or can be turned on and off into idle (known as C-states).
|
||||
A policy, or `governor', sets the CPU's frequency (P-state) when there is pending computation, optimizing performance at the expense of energy, or visa versa.
|
||||
The governor runs in conjunction with other policies, in particular (i) the scheduler -- which determines what tasks are run on what CPU cores and (ii) the idle policy -- which places CPUs with no pending work into a (idle) C-state.
|
||||
|
||||
Hardware design on phones can constrain governor policy calculations.
|
||||
For example, CPU speeds often cannot be set on individual cores but only on groups of CPUs -- a constraint stemming from the assymetric big-little CPU architecture, with 2 clusters of higher- and lower-performance CPU cores~\cite{big-little}.
|
||||
For example, CPU speeds often cannot be set on individual cores but only on groups of CPUs -- a constraint stemming from the asymetric big-little CPU architecture, with 2 clusters of higher- and lower-performance CPU cores~\cite{big-little}.
|
||||
|
||||
% idle paper: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=60fdaa6a74dec29a0538325b742bee4097247c6d#page=119
|
||||
|
||||
|
@ -37,7 +36,7 @@ We refer to the `speed' of the core in its idle state as $\fidle$
|
|||
|
||||
Many papers have studied the performance-energy trade-off of governors.
|
||||
Yao et al. \cite{492493} established an ideal framework, but assume prior knowledge of all workloads.
|
||||
Dynamic systems, by contrast, must somehow gague future work.
|
||||
Dynamic systems, by contrast, must somehow gauge future work.
|
||||
The common approach is to minimize energy usage subject to some performance constraint.
|
||||
Calculating the constraint -- pending work -- takes several approaches.
|
||||
The Polaris system \cite{korkmaz2018workload} tunes CPU speed to pending workloads based on userspace information.
|
||||
|
@ -46,7 +45,7 @@ It requires knowledge of the pending amount of work and deadline target, informa
|
|||
Instead of focusing on the current workload, Zhou et al. \cite{9591359} employ machine learning to predict it for a known QoS performance constraint.
|
||||
|
||||
Unsurprisingly, several studies have focused on the phone platform given the later's energy constraints, generally seeking to maintain user experience as the constraint.
|
||||
The system proposed by Chen et al. \cite{7372574, 8356047} gagues workload on phone games by tracking CPU-GPU interaction and dynamically selects among existing governors.
|
||||
The system proposed by Chen et al. \cite{7372574, 8356047} gauges workload on phone games by tracking CPU-GPU interaction and dynamically selects among existing governors.
|
||||
Li et al. \cite{10.1145/3061639.3062239, 9153119} go further, predicting future work by categorizing game graphic scenes.
|
||||
Broyde et al. \cite{8226044} combine scaling non-idle CPU count with CPU frequency to tune their system.
|
||||
The Maestro system \cite{8410428}, like ours, recognizes that existing policies can unduly overreact, resulting in CPU overperformance.
|
||||
|
@ -60,8 +59,9 @@ Zhisheng et al. \cite{10.1145/2973750.2973780} constrain streaming, analyzing th
|
|||
%% HERE...
|
||||
|
||||
Begem et al. take the opposite of the general approach and maximize performance pursuant to energy constraints on phones.\cite{7314145}
|
||||
A system that potentially constrains comptation resources needs to measure the cost.
|
||||
Meeting query latencies or screendraws are common measurements used in the previous studies.
|
||||
A system that potentially constrains computation resources needs to measure the cost.
|
||||
Meeting query latencies or screendraws are common measurements used in previous studies.
|
||||
None of these, to our knowledge, uses our approach of observing that an approximate energy-minimum setting already suffices to maintain acceptable performance targets, baring specific identifiable cases.
|
||||
|
||||
|
||||
|
||||
|
@ -70,7 +70,6 @@ Meeting query latencies or screendraws are common measurements used in the previ
|
|||
|
||||
|
||||
|
||||
None of these, to our knowledge, uses our approach of observing that an approximate energy-minimum setting already suffices to maintain acceptable performance targets, baring specific identifiable cases.
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue