Energy Management in Mobile Devices
`with the Cinder Operating System
`
`Arjun Roy, Stephen M. Rumble, Ryan Stutsman, Philip Levis, David Mazi`eres, Nickolai Zeldovich†
`Stanford University and MIT CSAIL†
`
`Abstract
`We argue that controlling energy allocation is an increas-
`ingly useful and important feature for operating systems, es-
`pecially on mobile devices. We present two new low-level
`abstractions in the Cinder operating system, reserves and
`taps, which store and distribute energy for application use.
`We identify three key properties of control – isolation, dele-
`gation, and subdivision – and show how using these abstrac-
`tions can achieve them. We also show how the architecture of
`the HiStar information-flow control kernel lends itself well
`to energy control. We prototype and evaluate Cinder on a
`popular smartphone, the Android G1.
`Categories and Subject Descriptors D.4.7 [Operating Sys-
`tems]: Organization and Design
`General Terms Design
`Keywords
`energy, mobile phones, power management
`
`Introduction
`1.
`In the past decade, mobile phones have emerged as a dom-
`inant computing platform for end users. These very per-
`sonal computers depend heavily on graphical user interfaces,
`always-on connectivity, and long battery life, yet in essence
`run operating systems originally designed for workstations
`(Mac OS X/Mach) or time-sharing systems (Linux/Unix).
`Historically, operating systems have had poor energy
`management and accounting. This is not surprising, as their
`APIs standardized before energy was an issue. For exam-
`ple, the first commodity laptop with performance similar
`to a desktop, the Compaq SLT/286 [Com 1988], was re-
`leased just one year before the C API POSIX standard.
`The resulting energy management limitations of POSIX
`have prompted a large body of research, ranging from CPU
`
`Permission to make digital or hard copies of all or part of this work for personal or
`classroom use is granted without fee provided that copies are not made or distributed
`for profit or commercial advantage and that copies bear this notice and the full citation
`on the first page. To copy otherwise, to republish, to post on servers or to redistribute
`to lists, requires prior specific permission and/or a fee.
`EuroSys’11, April 10–13, 2011, Salzburg, Austria.
`Copyright c(cid:13) 2011 ACM 978-1-4503-0634-8/11/04. . . $10.00
`
`scheduling [Flautner 2002] to accounting [Zeng 2003] to of-
`floading networking. Despite this work, current systems still
`provide little, if any, application control or feedback: users
`have some simple high-level sliders or toggles.
`This limited control and visibility of energy is especially
`problematic for mobile phones, where energy and power de-
`fine system lifetime. In the past decade, phones have evolved
`from low-function proprietary applications to robust multi-
`programmed systems with applications from thousands of
`sources. Apple announced that as of April 2010 their App
`Store houses 185,000 apps [App 2010] for the iPhone with
`more than 4 billion application downloads. This shift away
`from single-vendor software to complex application plat-
`forms means that the phone’s software must provide effec-
`tive mechanisms to manage and control energy as a resource.
`Such control will be even more important as the danger
`grows from buggy or poorly designed applications to poten-
`tially malicious ones.
`In the past year, mobile phone operating systems began
`providing better support for understanding system energy
`use. Android, for example, added a UI that estimates applica-
`tion energy consumption with system call and event instru-
`mentation, such as processor scheduling and packet counts.
`This is a step forward, helping users understand the myster-
`ies of mobile device lifetime. However, while Android pro-
`vides improved visibility into system power use, it does not
`provide control. Outside of manually configuring applica-
`tions and periodically checking battery use, today’s systems
`cannot do something as simple as controlling email polling
`to ensure a full day of device use.
`This paper presents Cinder, a new operating system de-
`signed for mobile phones and other energy-constrained com-
`puting devices. Cinder extends the HiStar secure kernel [Zel-
`dovich 2006] to provide new abstractions for controlling
`and accounting for energy: reserves and taps. Reserves are
`a mechanism for resource delegation, providing fine-grained
`accounting and acting as an allotment from which applica-
`tions draw resources. Where reserves describe a quantity of a
`resource, taps place rate limits on resources flowing between
`reserves. By connecting reserves to one another, taps allow
`resources to flow to applications. Taps and reserves compose
`
`139
`
`Apple and Samsung Ex. 1023
`Apple Inc., Samsung Electronics Co., Ltd., and
`Samsung Electronics America, Inc. v. Firstface Co., Ltd.
`IPR2019-00611
`Page 00001
`
`

`

`together to allow applications to express their intentions, en-
`abling policy enforcement by the operating system.
`Cinder estimates energy consumption using standard
`device-level accounting and modeling [Zeng 2002]. HiS-
`tar’s explicit information flow control allows Cinder to track
`which parties are responsible for resource use, even across
`interprocess communication calls serviced in other address
`spaces. Without needing any additional state or support
`code, Cinder can accurately amortize costs across principals,
`such as the energy cost of turning on the radio to multiple
`applications that simultaneously need Internet access.
`While Cinder runs on a variety of hardware platforms
`(AMD64, i386, ARM), the most notable is the HTC Dream,
`a.k.a. the Android G1. To the best of our knowledge, other
`than extensions to Linux, Cinder is the first research operat-
`ing system that runs on a mobile phone. The reason for such
`a first is simple: the closed nature of phone platforms makes
`porting an operating system exceedingly difficult.
`This paper makes three research contributions. First, it
`proposes reserves and taps as new operating system mech-
`anisms for managing and controlling energy consumption.
`Second, it evaluates the effectiveness and power of these
`mechanisms in a variety of realistic and complex application
`scenarios running on a real mobile phone. Third, it describes
`experiences in writing a mobile phone operating system, out-
`lining the challenges and impediments faced when conduct-
`ing systems research on the dominant end-user computing
`platform of this decade.
`
`2. A Case for Energy Control
`This section motivates the need for low-level, fine-grained
`energy control in a mobile device operating system. It starts
`by reviewing some of the prior work on energy visibility and
`the few examples of coarse energy control. Using several ap-
`plication examples as motivation, it describes three mecha-
`nisms an OS needs to provide for energy: isolation, dele-
`gation, and subdivision. The next section describes reserves
`and taps, abstractions which provide these mechanisms at a
`fine granularity.
`
`2.1 Prior Work on Visibility and Control
`Managing energy requires accurately measuring its con-
`sumption. A great deal of prior work has examined this prob-
`lem for mobile systems, including ECOSystem [Zeng 2002],
`Currentcy [Zeng 2003], PowerScope [Flinn 1999b], and
`PowerBooter [Zhang 2010]. These systems use a model of
`the power draw of hardware components based on hardware
`states. For example, an 802.11b card draws only slightly
`more power while transmitting than receiving, whereas a
`CPU’s power draw increases with utilization. Current mo-
`bile phone energy accounting systems, such as Android’s,
`use this approach. Cinder also does as well; Section 4 pro-
`vides the details.
`
`Early systems like ECOSystem [Zeng 2002] proposed
`mechanisms by which a user could control per-application
`energy expenditure. ECOSystem, in particular, introduced
`an abstraction called Currentcy, which gives an application
`the ability to spend a certain amount of energy, up to a fixed
`cap. This flat hierarchy of energy principals – applications
`– is reasonable for simple large applications. Mobile appli-
`cations and systems today, however, are far more complex
`and involve multiple principals. For example, web browsers
`run active code as well as possibly untrusted plugins, net-
`work daemons control access to the cellular data network,
`and peripherals have complex energy profiles.
`2.2
`Isolation, Delegation, and Subdivision
`We believe that for applications to effectively control energy,
`an operating system must provide three energy management
`mechanisms: isolation, delegation, and subdivision. We mo-
`tivate these mechanisms through application examples that
`we follow through the rest of the paper.
`The first mechanism is isolation. Isolation is a fundamen-
`tal part of an operating system. Memory and inter-process
`communication (IPC) isolation provide security, while CPU
`and disk space isolation ensure that processes cannot starve
`others. Isolating energy consumption is similarly important.
`An application should not be permitted to consume inordi-
`nate amounts of energy, nor should it be able to deprive other
`applications. Consider two processes in a system, each with
`some share of system energy. To improve system reliabil-
`ity and simplify system design, the operating system should
`isolate each process’ share from the other’s. If one process
`forks additional processes, these children must not be able
`to consume the energy of the other.
`The second mechanism is delegation. Delegation allows
`a principal to loan any of its available energy and power to
`another principal. After delegation, either the resource donor
`or the recipient can freely consume the delegated resources.
`Furthermore, if there are multiple donors delegating to this
`recipient, the resources are pooled for use by the recipi-
`ent. Resource delegation is an important enabler of inter-
`application cooperation. For example, the Cinder netd net-
`working stack transfers energy into a common radio activa-
`tion pool when an application cannot afford the high initial
`expense of powering up the radio. By delegating their energy
`to the radio, multiple processes can contribute to expensive
`operations; this may not only improve quality of service, but
`even reduce energy consumption.
`The third mechanism is subdivision. Subdivision allows
`applications to partition their available energy. Combined
`with isolation, subdivision allows an application to give an-
`other principal a partial share of its energy, while being as-
`sured that sure that the rest will remain for its own use.
`For example, modern web browsers commonly run plugins,
`some of which may even be untrusted. If a browser is granted
`a finite amount of power, it might want to protect itself from
`buggy or poorly written plugins that could waste CPU en-
`
`140
`
`IPR2019-00611 Page 00002
`
`Apple and Samsung Ex. 1023
`Apple Inc., Samsung Electronics Co., Ltd., and
`Samsung Electronics America, Inc. v. Firstface Co., Ltd.
`IPR2019-00611
`Page 00001
`
`

`

`ergy. Subdivision lets the browser give full control over a
`fraction of its energy allotment to plugins. Isolation further
`ensures that each plugin component does not consume more
`than its share.
`
`2.3 Prior Systems
`Prior systems like ECOSystem [Zeng 2002, 2003] only
`partially support isolation and subdivision: child processes
`share the resources of their parent. This is sufficient when
`applications are static entities, but not when they spawn new
`processes and invoke complex services. The web browser
`demonstrates the problem: it has no way to prevent its
`plugins from consuming its own resources once they are
`spawned. Cinder’s subdivision lends naturally to familiar
`and standard abstractions such as process trees, resource
`containers, and quotas.
`Furthermore, prior systems do not permit delegation,
`which is akin to priority inheritance. For always-on systems
`which have small variations in power draw, such as the lap-
`tops for which they were designed, this is not a serious lim-
`itation. On mobile phones, however, which have almost two
`orders of magnitude difference in active and sleep power, the
`cost of powering up peripherals, such as the wireless data in-
`terface, can be significant. Delegation provides a means to
`facilitate application cooperation.
`
`3. Design
`Cinder is based on HiStar [Zeldovich 2006], a secure op-
`erating system built upon information flow control. Cinder
`adds two new fundamental kernel object types: reserves and
`taps. This section gives a brief overview of HiStar and key
`features related to resource management, describes reserves
`and taps, gives examples of how they can be used, and details
`how they are secured.
`
`3.1 HiStar
`HiStar is composed of six first-class kernel objects, all pro-
`tected by a security label. Its segments, threads, address
`spaces, and devices are similar to those of conventional ker-
`nels. Containers enable hierarchical control over dealloca-
`tion of kernel objects – objects must be referenced by a con-
`tainer or face garbage collection. Gates provide protected
`control transfer of a thread from one address space to a
`named offset in another; they are the basis for all IPC.
`
`3.2 Reserves
`A reserve describes a right to use a given quantity of a re-
`source, such as energy. When an application consumes a
`resource the Cinder kernel reduces the values in the corre-
`sponding reserve. The kernel prevents threads from perform-
`ing actions for which their reserves do not have sufficient re-
`sources. Reserves, like all other kernel objects, are protected
`by a security label (§3.5) that controls which threads can ob-
`serve, use, and manipulate it.
`
`All threads draw from one or more energy reserves. Cin-
`der’s CPU scheduler is energy-aware and allows a thread to
`run only when at least one of its energy reserves is not empty.
`Threads that have depleted their energy reserves cannot run.
`Tying energy reserves to the scheduler prevents new spend-
`ing, which is sufficient to throttle energy consumption.
`Reserves allow threads to delegate and subdivide re-
`sources. As a simple example, an application granted 1000 mJ
`of energy can subdivide its reserve into an 800 mJ and a
`200 mJ reserve, allowing another thread to connect to the
`200 mJ reserve. However, threads rarely manage energy
`in such concrete quantities, preferring instead to use taps
`(§3.3). A thread can also perform a reserve-to-reserve trans-
`fer provided it is permitted to modify both reserves.
`Reserves also provide accounting by tracking applica-
`tion resource consumption. Applications may access this ac-
`counting information in order to provide energy-aware fea-
`tures. Finally, reserves can be deleted directly or indirectly
`when some ancestor of their container is deleted, just as a file
`can be deleted either directly or indirectly when a directory
`containing it is deleted in a Unix system.
`
`3.3 Taps
`A tap transfers a fixed quantity of resources between two
`reserves per unit time, which controls the maximum rate at
`which a resource can be consumed. For example, an appli-
`cation reserve may be connected to the system battery via a
`tap supplying 1 mJ/s (1 mW).
`Taps aid in subdividing resources between applications
`since partitioning fixed quantities is impractical for most
`policies. A user may want her phone to last at least 5 hours
`if she is surfing the web; the amount of energy the browser
`should receive is relative to the length of time it is used.
`Providing resources as a rate naturally addresses this.
`Another approach, which Cinder does not take, would be
`to implement transfer rates between reserves through threads
`that explicitly move resources and enforce rate-limiting as
`well as accounting. Given five applications, each to be lim-
`ited to consume an average of 1 W, the system could cre-
`ate five application reserves and threads, with each thread
`transferring while tracking and limiting energy into each
`of these applications’ reserves. However, this fine-grained
`control would cause a proliferation of these special-purpose
`threads, adding overhead and decreasing energy efficiency.
`Taps are made up of four pieces of state: a rate, a source
`reserve, a sink reserve, and a security label containing
`the privileges necessary to transfer the resources between
`the source and sink (§3.5). Conceptually, it is an efficient,
`special-purpose thread whose only job is to transfer en-
`ergy between reserves. In practice, transfers are executed
`in batch periodically to minimize scheduling and context-
`switch overheads.
`
`141
`
`IPR2019-00611 Page 00003
`
`Apple and Samsung Ex. 1023
`Apple Inc., Samsung Electronics Co., Ltd., and
`Samsung Electronics America, Inc. v. Firstface Co., Ltd.
`IPR2019-00611
`Page 00001
`
`

`

`Root
`
`Browser
`Reserve
`
`Figure 1. A 15 kJ battery, or root reserve, connected to a reserve
`via a tap. The battery is protected from being misused by the web
`browser. The web browser draws energy from an isolated reserve
`which is fed by a 750 mW tap.
`
`3.4 Resource Consumption Graph
`Reserves and taps form a directed graph of resource con-
`sumption rights. The root of the graph is a reserve represent-
`ing the system battery; all other reserves are a subdivision
`of this root reserve. Figure 1 shows a simple example of a
`web browser whose consumption is rate limited using a tap.
`The tap guarantees that even if the browser is aggressively
`using energy the battery will last at least 5 hours (15,000 J at
`0.750 J/s is about 5.6 hours).
`3.5 Access Control & Security
`Any thread can create and share reserves or taps to subdivide
`and delegate its resources. This ability introduces a problem
`of fine-grained access control. To solve this, reserves and
`taps are protected by a security label, like all other kernel
`objects. The label describes the privileges needed to observe,
`modify, and use the reserve or tap.
`Using resources from a reserve requires both observe and
`modify privileges: observe because failed consumption indi-
`cates the reserve level (zero) and modify for when consump-
`tion succeeds. Since a tap actively moves resources between
`a source and sink reserve, it needs privileges to observe and
`modify both reserve levels; to aid with this, taps can have
`privileges embedded in them.
`4. Cinder on the HTC Dream
`Controlling energy requires measuring or estimating its con-
`sumption. This section describes Cinder’s implementation
`and its energy model. The Cinder kernel runs on AMD64,
`i386, and ARM architectures. All source code is freely avail-
`able under open-source licenses. Our principal experimental
`platform is the HTC Dream (Google G1), a modern smart-
`phone based on the Qualcomm MSM7201A chipset.
`4.1 Energy accounting
`Energy accounting on the HTC Dream is difficult due to the
`closed nature of its hardware. It has a two-processor design,
`as shown in Figure 2. The operating system and applications
`run on an ARM11 processor. A secure, closed ARM9 co-
`processor manages the most energy hungry, dynamic, and
`informative components (e.g. GPS, radio, and battery sen-
`sors). The ARM9, for example, exposes the battery level as
`an integer from 0 to 100.
`Recent work on processors has shown that fine-grained
`performance counters can enable accurate energy estimates
`
`QDSP5 ,~ii
`
`ARM 11: Cinder,
`Application S/W
`
`Interrupts
`
`ODSP4
`
`(Telephony) 1t
`
`~Iii illlj
`Main Memory
`
`GSMRadio
`
`~
`
`Power/Banery
`Protected Peripherals
`
`Peripheral Devices
`
`Figure 2. The two ARM cores in the MSM7201A chipset. Cinder
`runs on the ARM11, whereas the ARM9 controls access to sensitive
`hardware including the radio and GPS. The two communicate via
`shared memory and interrupt lines.
`
`within a few percent [Economou 2006; Snowdon 2009].
`Without access to such state in the HTC Dream, however,
`Cinder relies on the simpler well-tested technique of build-
`ing a model from offline-measurements of device power
`states in a controlled setting [Flinn 1999b; Fonseca 2008;
`Zeng 2002]. Phones today use this approach, and so Cinder
`has equivalent accuracy to commodity systems.
`
`4.2 Power Model
`Our energy model uses device states and their duration to
`estimate energy consumption. We measured the Dream’s
`energy consumption during various states and operations.
`All measurements were taken using an Agilent Technolo-
`gies E3644A, a DC power supply with a current sense re-
`sistor that can be sampled remotely via an RS-232 interface.
`We sampled both voltage and current approximately every
`200 ms, and aggregated our results from this data.
`While idling in Cinder, the Dream uses about 699 mW
`and another 555 mW when the backlight is on. Spinning the
`CPU increases consumption by 137 mW. Memory-intensive
`instruction streams increase CPU power draw by 13% over
`a simple arithmetic loop. However, the HTC Dream does
`not have hardware support to estimate what percentage of
`instructions are memory accesses. The ARM processor also
`lacks a floating point unit, leaving us with only integer,
`control flow, and memory instructions. For these reasons,
`our CPU model currently does not take instruction mix into
`account and assumes the worst case power draw (all memory
`intensive operations).
`
`4.3 Peripheral Power
`The baseline cost of activating the radio is exceptionally
`high: small isolated transfers are about 1000 times more ex-
`pensive, per byte, than large transfers. Figure 3 demonstrates
`the cost of activating the radio and sending UDP packets
`to an echo server that returns the same contents. Results
`demonstrate that the overhead involved dominates the total
`
`f(t)
`
`t
`
`ARM 11: Cinder,
`Application S/W
`
`R
`
`ARM 9 (Closed):
`Modem, Power, GPS
`
`142
`
`IPR2019-00611 Page 00004
`
`Apple and Samsung Ex. 1023
`Apple Inc., Samsung Electronics Co., Ltd., and
`Samsung Electronics America, Inc. v. Firstface Co., Ltd.
`IPR2019-00611
`Page 00001
`
`

`

`Figure 3. Radio data path power consumption for 10 second
`flows across six different packet rates and three packet sizes. Short
`flows are dominated by the 9.5 J baseline cost shown in Figure 4.
`For this simple static test, data rate has only a small effect on the
`total energy consumption. The average cost is 14.3 J (minimum:
`10.5, maximum: 17.6).
`
`Figure 4. Cost of transitioning from the lowest radio power state
`to active. One UDP packet is transmitted approximately every
`40 seconds to enable the radio. The device fully sleeps after 20 sec-
`onds, but the average plateau consumes an additional 9.5 J of en-
`ergy over baseline (minimum 8.8 J, maximum 11.9 J). Power con-
`sumption for a stationary device can often be predicted with rea-
`sonable accuracy, but outliers, such as the penultimate transition,
`occur unpredictably.
`
`power cost for flows lasting less than 10 seconds in duration,
`regardless of the bitrate.
`Figure 4 shows this activation cost. An application pow-
`ers up the radio by sending a single 1-byte UDP packet. The
`secure ARM9 automatically returns to a low power mode
`after 20 seconds of inactivity. Because the ARM9 is closed,
`Cinder cannot change this inactivity timeout.
`With this workload, it costs 9.5 joules to send a single
`byte! One lesson from this is that coordinating applications
`to amortize energy start-up costs could greatly improve en-
`ergy efficiency. In §5.5 we demonstrate how Cinder can use
`reserves and taps for exactly this purpose.
`
`4.4 Mobility & Power Model Improvements
`Cinder’s aim is to leverage advances in energy accounting
`(see §8.2) to allow users and applications to provision and
`manage their limited budgets. Accurate energy accounting
`is an orthogonal and active area of research. Cinder is adapt-
`able and can take advantage of new accounting techniques
`or information exposed by device manufacturers.
`
`// Create a reserve
`object_id_t res_id;
`res_id = reserve_create(container_id, res_label);
`objref res = OBJREF(container_id, res_id);
`
`// Create a tap and connect it between
`// the battery and the new reserve
`object_id_t tap_id;
`tap_id = tap_create(container_id, root_reserve,
`res, tap_label);
`objref tap = OBJREF(container_id, tap_id);
`// Limit the child to 1 mW
`tap_set_rate(tap, TAP_TYPE_CONST, 1);
`
`if (fork() == 0) {
`// child process: switch to new reserve before exec
`self_set_active_reserve(res);
`execv(args[0], args);
`
`}
`
`Figure 5. energywrap excerpt without error handling.
`
`5. Applications
`To gain experience with Cinder’s abstractions, we devel-
`oped applications using reserves and taps. This section de-
`scribes these applications, including a command-line utility
`that augments existing applications with energy policies, an
`energy constrained web browser that further isolates itself
`from its browser plugins, and a task manager application that
`limits energy consumption of background applications.
`
`5.1 energywrap
`Taking advantage of the composability of Cinder’s resource
`graph, the energywrap utility allows any application to be
`sandboxed even if it is buggy or malicious. energywrap
`takes a rate limit and a path to an application binary. The
`utility creates a new reserve and attaches it to the reserve in
`which energywrap started by a tap with the rate given as
`input. After forking, energywrap begins drawing resources
`from the newly allocated reserve rather than the original re-
`serve of the parent process and executes the specified pro-
`gram. This allows even energy-unaware applications to be
`augmented with energy policies.
`The sandboxing policy provided by energywrap is im-
`plemented in about 100 lines of C++. An excerpt is shown
`in Figure 5. HiStar provides a wrap utility designed to iso-
`late applications with respect to privileges and storage re-
`sources. Coupling this utility with energywrap allows any
`application or user to provide a virtualized environment to
`any thread or application. Section 6.1 evaluates the effec-
`tiveness of energy sandboxing and isolation.
`energywrap has proved useful in implementing policies
`while designing and testing Cinder, particularly for legacy
`applications that have no notion of reserves or taps. Since
`energywrap runs an arbitrary executable, it is possible to
`use energywrap to wrap itself or shell scripts, which may
`invoke energywrap with other scripts or applications. This
`
`10 Second Flow Energy Usage Across Packet Sizes and Rates
`
`1500 bytes/pkt
`750 bytes/pkt
`1 bytes/pkt
`
` 40
` 35
` 30
` 25
` 20
` 15
` 10
` 5
` 0
`
`Joules
`
` 0
`
` 5
`
` 10
`
` 15
`
` 20
`
` 25
`
` 30
`
` 35
`
` 40
`
`Packets per Second
`
`Radio Activation Power Draw
`
` 2
`
` 1.5
`
` 1
`
` 0.5
`
` 0
`
`Watts
`
` 0
`
` 50
`
` 100
`
` 150
`
` 200
`
` 250
`
` 300
`
` 350
`
` 400
`
`Seconds
`
`143
`
`IPR2019-00611 Page 00005
`
`Apple and Samsung Ex. 1023
`Apple Inc., Samsung Electronics Co., Ltd., and
`Samsung Electronics America, Inc. v. Firstface Co., Ltd.
`IPR2019-00611
`Page 00001
`
`

`

`(a)
`
`Figure 6. (a) A web browser configured to run for at least 6 hours
`on a 15 kJ battery. The web browser further ensures that its plugin
`cannot use more than 10% of its energy. (b) Adding 0.1x backward
`proportional taps promotes sharing of excess energy unused by the
`browser and plugin.
`
`allows a wide class of ad hoc policies to be scripted using
`standard shell scripting or on-the-fly at the command line.
`
`5.2 Fine-grained Control
`Mobile browsers now support plugins like Adobe Flash [Fla
`2009], and we can expect more plugins and extensions to
`follow. On a device where resources are precious, it is im-
`portant to have tight control over these plugins.
`In Cinder, an application may be given some fixed rate or
`quota of energy using reserves and taps. A web browser may,
`for example, want to also run a plugin while ensuring that it
`cannot starve other plugins or even the browser itself. Shown
`in Figure 6a, the browser can allocate a separate reserve for
`the plugin and connect it to its own energy via a low rate tap.
`Often a single plugin (e.g. Flash) may be handling a
`number of pages or requests all in a single process. To scale
`the energy given to the plugin with the number of pages
`it is handling, the browser can add a tap per page. When
`a particular page is no longer being handled (e.g. the user
`navigates away) the taps associated with that page can be
`automatically garbage collected, effectively revoking those
`power sources.
`Cinder includes a simple graphical web browser based
`on links2 that runs in Xorg or standalone against the frame-
`buffer. It is augmented with an extension running in a sepa-
`rate process, whose energy usage is subdivided and isolated
`from the browser. The browser can send requests to the ex-
`tension process (for ad blocking, etc.), and if the extension is
`unresponsive due to lack of energy the browser can display
`the unaugmented page.
`
`5.2.1 Reclaiming Unused Resources
`Consider a problem common to many applications: a web
`browser would like to allow a plugin to consume resources
`quickly while making sure it shares unused resources. The
`plugin may fully utilize peripherals and drive the device at
`peak power, requiring a reserve fed with a high rate tap. This
`raises a problem: if the plugin draws less than its tap rate, the
`
`reserve will slowly fill with energy that no other application
`can use.
`To solve this problem, an application can use a propor-
`tional tap. These taps transfer a fraction of their source re-
`serve’s resource per unit time, rather than a fixed quantity.
`Figure 6b shows the fix to the browser; the plugin reserve
`on the right is limited to a maximum average power draw of
`70 mW. The backwards proportional tap means the plugin
`reserve can store up to 10 s of this power (700 mJ) for bursty
`operations. Once the reserve reaches 700 mJ, the backwards
`proportional tap drains the reserve as quickly as the forward
`constant tap fills it. Similarly, the browser’s reserve can ac-
`cumulate up to 7000 mJ while being forced to share unused
`energy with other applications.
`5.2.2 Hoarding and Resource Decay
`Backward proportional taps alone are insufficient for pre-
`venting malicious applications from hoarding. Threads can
`sidestep taxation by creating a new reserve with no propor-
`tional taps and periodically transferring resources to it. The
`application could, over time, accumulate energy equal to the
`battery and starve the rest of the system.
`To prevent this, Cinder could provide a reserve clone()
`rather than reserve create(). This call would take a re-
`serve that an application has access to and create a new
`reserve taking care to duplicate any backward proportional
`taps that the application does not have the permission to re-
`move. Additionally, Cinder would need to disallow system
`calls that transfer resources from a fast-draining reserve to a
`more slow-draining reserve unless the caller has proper per-
`mission (that is, the permission to remove all the backward
`taps from the source reserve that do not have a correspond-
`ing backward tap at the target reserve).
`These constraints eliminate hoarding, but complicate ap-
`plications that are not malicious. Therefore, in practice, Cin-
`der prevents hoarding by imposing a global, long-term decay
`of resources across all reserves; every reserve has an implicit
`proportional backward tap to the battery.
`By default, Cinder is configured to leak 50% of reserve
`resources after a period of 10 minutes. This long (but short
`compared to the period between battery recharges) half-life
`allows applications to accumulate and store energy for sig-
`nificant periods, and permits the system to make large-scale
`long-term hoarding impossible. ESX Server [Waldspurger
`2002] successfully uses a similar “idle memory tax” to miti-
`gate hoarding of unused memory between virtual machines.
`Further experience with these abstractions is needed to
`understand whether the trade-offs associated with the more
`fundamental solution for hoarding are worth making.
`5.3 Energy-Aware Applications
`Using Cinder, developers can gain fine-grained control of
`resources within their applications, providing a better expe-
`rience to end users. This includes adaptive policies for pro-
`grams where partial or degraded results are still useful, and
`
`144
`
`IPR2019-00611 Page 00006
`
`Apple and Samsung Ex. 1023
`Apple Inc., Samsung Electronics Co., Ltd., and
`Samsung Electronics America, Inc. v. Firstface Co., Ltd.
`IPR2019-00611
`Page 00001
`
`

`

`Figure 7. RSS is running in the foreground so the task manager
`has set its tap to give it additional power. Mail is running in
`the background, and can only draw energy from the background
`reserve. This ensures that actual battery consumption matches the
`user’s expectation that the visible application is responsible for
`most energy consumption.
`
`offer a compromise between battery life and user experi-
`ence. For example, smart applications may scale the quality
`of streaming video or reduce texture quality in a game when
`available energy is low, since the user can still watch a video
`or play a game when insufficient resources are available to
`run at full fidelity.
`As a concrete example, we have implemented an energy-
`aware network picture gallery. The application has a sepa-
`rate thread for do