space edits
This commit is contained in:
commit
4d49ad7aab
|
@ -86,7 +86,11 @@ We evaluate six different CPU policies under different workloads:
|
||||||
(iv) a truncated \schedutil implemented with \systemname,
|
(iv) a truncated \schedutil implemented with \systemname,
|
||||||
(v) unmodified \systemname, and
|
(v) unmodified \systemname, and
|
||||||
(vi) the \texttt{performance} governor.
|
(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 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}.
|
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.
|
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 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.
|
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.
|
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.
|
It runs the original Facebook workload in the foreground while the Spotify app streams audio continuously in the background.
|
||||||
|
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
\subsection{Screen Jank}
|
\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).
|
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.
|
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.
|
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.
|
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.
|
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.
|
The truncated \schedutil policies and fixed speed 70\% policy also offer improved sreendrop rates.
|
||||||
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
\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$.
|
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$.
|
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.
|
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.
|
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.
|
\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.
|
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.
|
As with Facebook, both Youtube and Spotify shows a much flatter relationship, particularly on the big cores.
|
||||||
\todo{Discuss Spotify}
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue