edits

sections/evaluation.tex

@@ -79,7 +79,7 @@ Information on screen performance including framedrops came from the Android \te
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \paragraph{CPU Policies}
-We evaluate six different CPU policies under different workloads:
+We evaluate six different CPU policies:
 (i) the system default, \schedutil,
 (ii) a truncated \schedutil implemented by lower-bounding the CPU using the existing API discussed in subsection \ref{subsec:signal_perf_needs},
 (iii) a fixed 70\% speed using the existing \texttt{userspace} governor,
@@ -108,7 +108,7 @@ These workloads address evaluation claim (iii).
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsection{Screen Jank}
 
-\Cref{fig:jank_allapps} shows frame drop rates for the four workloads.
+\Cref{fig:jank_allapps} shows frame drop rates.
 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 (12.6 frames per minute) at a 60fps display rate.

sections/wasted.tex

@@ -56,7 +56,7 @@ Armed with this knowledge, we realize the \systemname governor: a simple policy
 
 \paragraph{Case Studies}
 We studied a range of apps, including Facebook, Youtube, and Spotify.  
-For each app, we developed a simple, short scripted interaction to study in terms of its performance characteristics and energy usage. 
+For each app, we developed a short scripted interaction to study  its performance characteristics and energy usage. 
 We focus here primarily on the Facebook workload that we previously introduced in \Cref{sec:low-speed-in-practice}, and return to the other workloads to verify our findings in \Cref{sec:evaluation}.
 Our first goal is to understand what user-perceivable value this energy overhead obtains for us.
 
@@ -84,9 +84,7 @@ During this time, the user is waiting on the app to become responsive.
 It makes sense under such circumstances to run the CPUs at a higher speed to enhance user experience.
 
 Figure \ref{fig:coldstart_time_spot} shows the results of a study to examine the benefits and costs of doing this.
-
 Bear in mind that the unmodified system already uses the .. to provide a minimal $\sim$.5s boost to CPU speed.
-
 Ironically, the largest benefit comes in energy saved...
 
 
@@ -117,7 +115,7 @@ Even running the CPU at full speed, the system has more work.
   Adaptive widgets in mobile apps present an effectively infinite source of work to mobile CPUs over finite windows of interaction.
 }
 
-By adapting itself to the available CPU power, Facebook signals an effectively infinite source of work to the governor, which responds by ramping the CPU up to full speed.
+By adapting to the available CPU power, Facebook signals an effectively infinite source of work to the governor, which responds by ramping the CPU up to full speed.
 In this situation, speeds above $\fenergy$ may actually provide a perceptible benefit.
 However, even at the CPU's maximum frequency, more work is created than the CPU can keep up with.