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

space edits

master
Lukasz Ziarek 2023-08-25 21:57:51 -04:00
parent f5ab6dc178 5a54aecac6
commit 4d49ad7aab
1 changed files with 13 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
sections/evaluation.tex
View File

@ -86,7 +86,11 @@ We evaluate six different CPU policies under different workloads:
(iv) a truncated \schedutil implemented with \systemname,
(v) unmodified \systemname, and
(vi) the \texttt{performance} governor.
<<<<<<< HEAD
We include (ii) and (iii) to compare the general performance of the truncated \schedutil and a general-case $\sim$70\% speed policies when implemented under the existing API with that when implemented using \systemname.
=======
We include (ii) and (iii) to compare the general performance of the truncated \schedutil and a common-case $\sim$70\% speed policies when implemented under the existing API with the equivalents implemented using \systemname.
>>>>>>> 5a54aecac642577b25bdd5ae50dbe55c0103d47a
Under default Linux, a specific CPU speed requested gets implemented as the next-highest speed in a preset series of supported speeds in \texttt{scaling\_available\_frequencies} in \texttt{sysfs}.
We follow this behavior with our system.
@ -101,22 +105,23 @@ The app selects the first hit, starts the video, and waits for 30 seconds.
The specific video was selected to get a predictable high rate of being served random motion video ads at the start.
The \textbf{Spotify} workload starts the app searches for a common musical selection.
It starts the first suggestion and waits for 30 seconds while the audio plays with the app in the foreground.
Lastly, the \textbf{Combined} workload examines the system under additional stress.
Lastly, the \textbf{Combined} workload examines the system under commonplace additional stress.
It runs the original Facebook workload in the foreground while the Spotify app streams audio continuously in the background.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Screen Jank}
\Cref{fig:jank_allapps} show frame drop rates for the four workloads.
\Cref{fig:jank_allapps} shows frame drop rates for the four workloads.
These graphs address the performance aspect of claims (i) and (ii).
On all workloads, \systemname and truncated \schedutil offer nearly identical or notably better performance than regular \schedutil.
The Facebook load under \systemname costs an additional .3\%, or $\sim$.2 frames per second at 60fps.
We argue this does not noticeably affect user experience and is more than acceptable given the greater than 10\% energy savings.
The results of the truncated \schedutil policies and of fixedspeed 70\% similar offer significant energy savings at small to zero cost.
The results of the truncated \schedutil policies and of fixedspeed 70\% similarly offer significant energy savings at small to zero cost.
Youtube shows a clear performance win for \systemname compared to the default.
The truncated \schedutil policies and fixed speed 70\% policy also offer improved performance to the default.
Performance under \systemname for both Spotify and the Combined workloads, like that for Facebook, costs .3\% fps compared to the default -- a cost we again argue is very minimal and acceptable.
The truncated \schedutil policies and fixed speed 70\% policy also offer improved sreendrop rates.
Performance under \systemname for both the Spotify and the Combined workloads, like that for Facebook, costs .3\% fps compared to the default -- a cost we again argue is both very minimal and acceptable.
The other non-default policies for both Spotify and Combined also offer either essentially the same or even somewhat better performance than the default.
Particularly, the increased background load of Combined does not change screendrop rate appreciably.
In summary: \systemname, with a considerably simpler policy mechanism, offers essentially the same performance, measured in user experience screendrops, to that of \systemname, in common app workloads.
@ -126,7 +131,8 @@ In summary: \systemname, with a considerably simpler policy mechanism, offers e
To attribute the improvement in performance, we measure the CPU frequencies selected by \schedutil and \systemname, respectively.
\Cref{fig:time_per_freq_fb,fig:time_per_freq_yt,fig:time_per_freq_spot} plot a CDF of the difference between these two selections.
We note that for a significant fraction of the workload (5\% for Facebook, 15\% for Youtube), the frequency selected by \schedutil is significantly (up to 50\%) lower.
This addresses claim (iv) from above:
We note that for a significant fraction of the workload (5\% for Facebook, 15\% for Youtube, 12\% for Spotify), the frequency selected by \schedutil is significantly (up to 50\%) lower.
This is \schedutil's ramp-up period, where it selects frequencies lower than $\fenergy$.
We attribute the improved performance for both governors to eliminating the ramp-up period where \systemname selects speeds below $\fenergy$.
Although each workload spends part of its time at a higher frequency in \schedutil compared to \systemname, it spends more time ramping up to $\fenergy$ than at a higher speed.
@ -168,8 +174,6 @@ In common settings, background load does not pose a threat to the performance of
We next review our findings from \Cref{sec:adaptiveApps}, that typical apps increase their offered load as CPU capacity increases.
\Cref{fig:nonidle_fb,fig:nonidle_yt,fig:nonidle_spot} illustrate the fraction of the of time the CPU spends doing work in each workload as CPU frequency increases.
Recall that, assuming the amount of work stays constant in a fixed-duration workload, the time spent non-idle would show an inverse-linear relationship with the CPU frequency.
As with Facebook, the Youtube workload shows a much flatter relationship, particularly on the big cores.
\todo{Discuss Spotify}
As with Facebook, both Youtube and Spotify shows a much flatter relationship, particularly on the big cores.