|
|
1
2
|
\section{introduction}
|
|
|
3
|
\begin{comment}
|
|
|
4
5
6
7
8
9
|
Current operating systems are already proficient at managing certain system
resources, such as the CPU, memory, and disk. But on interactive mobile devices,
users care more about resources such as time, battery life, and money, that are
unmanaged or poorly managed by today's smartphone platforms.
When apps slow down our typing, they waste our time. When apps download
unnecessary resources, they waste battery life and potentially money, if using
|
|
|
10
|
a metered data plan. It is the degree to which mobile devices effectively
|
|
|
11
12
13
|
manage these human-facing resources that determines a user's
\textit{quality of experience} (QoE), and it is QoE which should drive not just
policy, but decisions on mobile devices.
|
|
|
14
|
\end{comment}
|
|
|
15
16
17
18
19
20
|
\begin{sloppypar}
While modern operating systems such as Android make decisions based on policies
meant to improve QoE, it is unclear that these static policies always result
in the right decisions. For example, Android uses two mechanisms to control the
underlying task scheduling in Linux: thread priority and control groups (cgroup).
|
|
|
21
|
Background threads -- threads running in another app, or low priority threads
|
|
|
22
|
running in the foreground app -- are placed in a cgroup that receives a very
|
|
|
23
|
limited share of the processor, \( \approx \) 5\% on Nexus 5 running stock
|
|
|
24
|
Android 5.1.1. Furthermore, the scheduler considers thread priority for tasks within
|
|
|
25
|
the same cgroup. However, thread priorities can be set by app developers both
|
|
|
26
|
directly through the API, and indirectly by using an \texttt{AsyncTask}.
|
|
|
27
28
29
30
31
32
33
|
While this policy was created based on the assumed effect on QoE, it is still
possible to negatively affect QoE by assigning the wrong priority to a thread
or by inappropriately using \texttt{AsyncTasks}.
\end{sloppypar}
The \texttt{ondemand} CPU frequency governor that is enabled in Android
Linux is another example of where static policy meant to improve QoE may not
|
|
|
34
|
result in correct decisions. This governor changes the CPU frequency
|
|
|
35
36
37
38
|
depending on the current CPU load with the goal of improving performance.
However since running at higher frequencies is less efficient, this increased
performance comes at the cost. If QoE would not be improved by increasing the
frequency, such as for time-insensitive background tasks or when the performance
|
|
|
39
40
|
increase would not be perceivable, negative QoE may manifest itself through
poor battery life.
|
|
|
41
|
|
|
|
42
|
%\newpage
|
|
|
43
44
45
46
|
In terms of QoE, static policies can lead to resource allocation decisions that
are less than optimal. To remedy this, we propose designing QoE-centric
mobile operating systems that use QoE as input to drive resource allocation
decisions.
|
