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

edits (cleanup)

master
carlnues@buffalo.edu 2023-08-26 07:24:44 -04:00
parent 395058197d
commit ac0761ce9c
1 changed files with 5 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
sections/wasted.tex
View File

@ -200,25 +200,13 @@ However, this information is not available, forcing \schedutil to employ a simpl
However, (i) adaptive apps offer an effectively infinite amount of work, (ii) micro-managing frequencies comes at a cost, and (iii) increasing CPU above $\fenergy$ does not meaningfully affect jank.
These observations, coupled with already extant adoption of the \texttt{prio\_hint} syscall in Android, drive our second governor proposal: \systemname.
\systemname, summarized in \Cref{alg:fullKiss} leverages boost requests provided by userspace through \texttt{/dev/stune}.
Recall that this API can be used to assign each task a \texttt{boost} value (between 0 and 100).
Instead of scaling usage history (like \schedutil), \systemname instead treats this value as a direct, fractional request for CPU performance:
A \texttt{boost} value of 100 is interpreted as a request for the CPU's maximum frequency (denoted $\fperf$).
\systemname selects the highest frequency of any scheduled task, with $\fenergy$ as a lower-bound.
\systemname leverages boost requests provided through userspace.
Recall that the \texttt{/dev/stune} API can be used to assign each task a \texttt{boost} value.
Instead of scaling usage history (like \schedutil), \systemname instead simply treats a boost value as a direct request for CPU performance.
\systemname selects the highest frequency of any scheduled task, with $\fenergy$ as a default lower-bound.
If no tasks are pending, it idles the CPU.
\begin{algorithm}
\caption{\texttt{KISS}($\mathcal T$)}
\label{alg:fullKiss}
\begin{algorithmic}
\Require $\mathcal T$: The set of currently scheduled tasks
\Ensure $f$: The target CPU frequency
\State $\mathcal F \gets \left\{\left.\; \frac{t.\texttt{boost}}{100}\cdot \fperf \;\right|\; t \in \mathcal T \;\right\} \cup \{ $ $\fenergy$ $\}$
\State \textbf{if} {$|\mathcal T| > 0$} \textbf{then} $f = \max(\mathcal F)$ \textbf{else} $f = $ $\fidle$ \textbf{end if}
\end{algorithmic}
\end{algorithm}
%%% A2
\paragraph{Security Concerns}
Allowing apps to pin the core to $\fperf$, could in principle, extend the attack surface for the Android kernel.