A Portable Interface for Runtime Energy Monitoring:Extended Analysis

Connor Imes ∗

University of Chicago

ckimes@cs.uchicago.edu

Lars BergstromMozilla Research

larsberg@mozilla.com

Henry HoffmannUniversity of Chicago

hankhoffmann@cs.uchicago.edu

ABSTRACT

As energy consumption becomes a first class concern for comput-ing systems, there is an increasing need for application-level ac-cess to runtime power/energy measurements. To support this need,a growing number of power and energy monitors are being de-veloped, each with their own interfaces. In fact, the approachesare extremely diverse, and porting energy-aware code to new plat-forms with new hardware can involve significant rewriting effort.To reduce this effort and support portable, application-level energymonitoring, a common interface is needed. In this paper, we pro-pose EnergyMon, a portable application interface that is indepen-dent of underlying power/energy data sources. We demonstrate En-ergyMon’s flexibility with multiple case studies, including energy-aware profiling and self-adaptive systems, which require monitor-ing energy across a range of hardware from different manufactur-ers. We release the EnergyMon interface, implementations, utili-ties, and Java and Rust bindings and abstractions as open source.

1. INTRODUCTIONPower and energy consumption are becoming increasingly im-

portant measures of software quality, especially as battery-drivenmobile platforms become ubiquitous. Even small improvements inpower/energy management can save significant amounts of batteryand extend a system’s usable runtime by hours. As a result, thereis a growing need for software to access power/energy data in-situ.However, accessing that data requires writing system-specific codewhich is challenging for engineers and results in applications thatare not portable across platforms.

The diversity in sensor properties and current ad-hoc approachesfor using them presents a significant challenge in accessing runtimepower/energy measurements. The problem is more complex thansimply locating and reading the correct files, hardware registers,or memory addresses. Other factors must be considered. Somesensors report energy while others report power. Energy counterseventually overflow. Some sensors, particularly external devices,require exclusive access. Each may use different units of measure-

ment with various levels of precision. All sensors have refresh in-

tervals. Sensors which only report power data must be polled attheir refresh interval so as not to lose data after the sensor refreshes.Power/energy readings may need to be extracted from other data

or transformed before they are meaningful [32, 35, 42]. Develop-

∗This work was partially conducted while Connor Imes was atMozilla Research.The University of Chicago’s effort on this project is funded by

the U.S. Government under the DARPA BRASS program, by theDept. of Energy under DOE DE-AC02-06CH11357, by the NSFunder CCF 1439156, and by a DOE Early Career Award.

ers may even have to implement different protocols and data for-

mats [32, 42]. Furthermore, even a single system equipped withpower or energy monitoring can offer multiple approaches to ob-tain it [10, 21, 35]. Correctly and accurately collecting power andenergy data requires understanding and properly managing sensorproperties and behavior.

Despite these difficulties, software increasingly relies on powerand energy metrics. In general, software systems that use this datafall into two categories: profilers that characterize an application’spower and energy usage, and self-adaptive applications that ac-tively modify their behavior to manage power or energy consump-tion. Power/energy profiling is important for applications rang-ing from mobile/embedded platforms [2, 13, 29, 33, 36, 46] tomore traditional end user systems and High Performance Com-puting environments [9, 25, 43]. Other approaches create self-adaptive applications [6, 24, 37] that change their runtime behaviorto achieve better energy efficiency or respect runtime power/energyconstraints [1, 12, 14, 17, 20, 40]. However, all this prior work usesad-hoc power/energy monitoring approaches. None have proposeda common, portable approach for exposing the required energy con-sumption data to software.

A common application interface for portable and practical accessto power and energy monitoring hardware is clearly needed. Tothis end, we propose EnergyMon, the first application-level inter-face designed specifically for exposing energy metrics from diversesources in a portable manner.

This paper makes the following contributions:• Describes the challenges and importance of capturing run-

time energy metrics in software, motivating the need for acommon interface.

• Proposes EnergyMon, a portable API for capturing energydata from diverse sources.

• Demonstrates EnergyMon’s versatility using performance/powerapplication and system characterization, power/energy-awareprofiling, and self-adaptive applications as case studies, exe-cuted on various platforms with different power/energy datasources and distinct performance/energy behavior.

• Open-source release of the EnergyMon API, current imple-mentations, bindings and abstractions in Java and Rust, andadditional utilities.1

Furthermore, EnergyMon is publicly available in Servo, Mozilla’sparallel web browsing engine [3] (see Section 5).

2. BACKGROUND AND MOTIVATIONThis section motivates the need for a portable, application-level

energy monitoring interface. We first discuss the challenges pre-

1Available at https://github.com/energymon

Table 1: Diverse properties of power/energy data sources.Nickname Data Source Data Type Access Units (Dec. Precision) Overflow Refresh Interval Interface

msr Intel MSR via msr kernel module [35] Energy Shared platform-specific 32 bits 1 ms dev file(s)rapl Intel MSR via intel_rapl kernel module [10] Energy Shared microjoules platform-specific 1 ms sysfs files

odroid TI INA-231 sensors [21] Power Shared watts (6) - 264 ms sysfs filesodroid-ioctl TI INA-231 sensors [21] Power Shared microwatts - 264 ms dev files

osp ODROID Smart Power via hidapi [15, 32] Energy Exclusive watt-hours (3) 1000 Wh 200 ms USBosp-polling ODROID Smart Power via hidapi [15, 32] Power Exclusive watts (3) - 200 ms USB

wattsup WattsUp? meter [42] Power Exclusive deciwatts - 1 sec USBshmem Shared memory provider Energy Shared microjoules provider-managed provider-dependent memorydummy None - Shared - - - memory

sented by the array of different power and energy sensors avail-able across modern hardware platforms. We then demonstrate theimportance of collecting runtime energy data by discussing priorwork in building software systems for both energy profiling andself-adaptive power/energy management.

2.1 ChallengesAs power and energy consumption become ever more crucial

measures of software quality, hardware power and energy sensorsare becoming more prevalent in computing systems. The diversityof available sensors complicates the process of collecting and in-terpreting the data they produce. Any portable interface for energymonitoring must account for the following differences:• Data Type: Whether sensors expose power or energy data.• Access: Access privileges/constraints, e.g., exclusiveness.• Units of measurement: The power or energy units that sen-

sors expose measurements in, and their precision.• Overflow: Maximum values for sensor counters.• Refresh Interval: How frequently sensors update.• Interface: System abstractions, protocols, and data formats.

Table 1 demonstrates these differences for the data sources usedin this work. The first column are the nicknames we use to referto the sensor access implementations, the second describes the un-derlying data source, and the rest present the details for propertieslisted above. The fact that refresh intervals span three orders ofmagnitude, from the MSR’s 1 ms to the WattsUp?’s 1 second, ex-emplifies how diverse sensors can be. In some cases there are evenmultiple implementations for the same data source because theyexpose multiple data types or interfaces.

One property that necessitates further discussion is the data type

– whether sensors expose power or energy data. Assume a sensorexposes cumulative energy data. Software that requires energy datasimply takes the difference in readings at the beginning and end ofthe event being evaluated. Software interested in power does thesame, but divides the difference in energy by the elapsed time toget an average power. Power sensors expose a value that is the av-erage power over an interval (e.g., one second), and are more com-plicated to use. To record energy, software must read the power ineach interval, multiply that value by the refresh interval to computeenergy, and keep a running total. Algorithm 1 demonstrates thisapproach. If the power sensor refreshes before its value is read, theenergy consumption over that interval is lost since the next powervalue may be different. Software interested in power must also pollat the refresh interval and keep a running average of the readingsduring the desired time interval.

Software that reads from a power or energy data source must un-derstand its behavior in order to use it properly. Such a task may in-volve managing sensor polling threads, tracking elapsed time, lim-iting the frequency of sensor accesses, performing I/O, parsing andtransforming data readings to consistent units, and sharing the datawith other software components. For example, our energy monitorsfor the data sources listed in Table 1 require roughly 250-300 linesof code on average. Without a portable interface, software that

Algorithm 1 Computing Energy from Power Sensors.

Require: PowerS ensor ⊲ The power sensorRequire: Re f reshInterval ⊲ The sensor’s refresh interval

Energy← 0 ⊲ Energy counter, initialized to 0

function PollPowerSensor ⊲ Local functionloop

Wait(Re f reshInterval)Power ← ReadPower(PowerS ensor)Energy← Energy + Power × Re f reshInterval

end loop

end function

function ReadEnergy ⊲ Externally visible functionreturn Energy

end function

relies on power or energy data must contain all of this platform-specific code to account for the diversity in data sources.

2.2 Power and Energy-Aware SoftwareSoftware requires runtime access to energy data for various pur-

poses including profiling and self-adaptation.Power and Energy-Aware Profiling: With the proliferation of

energy-constrained systems like smartphones, tablets, and now theInternet of Things, power and energy-aware profiling has becomeincreasingly important for developers who previously have not beenconcerned with this aspect of software behavior. PowerScope is oneof the early works that recognized the importance of profiling en-ergy usage for mobile applications [13]. More recently, Banerjee etal. used Android device power profiles to detect energy hotspotsand bugs in applications [2]. Other research has proposed newpower modeling techniques, investigated the behavior of SoCs orcomponents like GPS and cameras, and explored power behav-ior that is unique to smartphones like tail power states and wake-locks [30, 33, 34, 36, 46]. Power and energy-aware profiling is notlimited to mobile applications and devices. Cui et al. instrumentPC hardware to capture power with fine-grained time granularityas low as 20 microseconds [9]. PAPI 5 provides access to hardwareperformance counters including those that measure power/energydata exposed by common hardware in HPC environments [43].

Self-Adapting Applications: Applications that monitor and ad-just their behavior at runtime to obey performance, power, and en-ergy constraints are becoming more common [37]. Software caneven exhibit contrasting power/energy behavior on different hard-ware [18]. To address these problems, some applications accesspower/energy data in deployment to automatically adapt their be-havior. The Green language creates adaptive applications that min-imize energy given an acceptable accuracy [1], while the Eon lan-guage and runtime adapt embedded applications to the availabilityof harvested energy [40]. The Odyssey [14], GRACE [41, 44],CoAdapt [16], JouleGuard[17] and xTune [22] projects automati-cally coordinate applications and systems to meet real-time goals

with reduced energy in mobile and embedded systems, while Mo-hapatra et al. provide a similar framework for distributed systems[31]. The POET library enables applications to tune their own re-source usage to meet soft real-time constraints with minimal en-ergy [20]. Similar projects automatically tune server applicationsto meet power goals with maximum performance [7, 19, 45]. Kleinet al. recently proposed a technique to alter webpage content basedon available energy and power resources [23].

2.3 The Need for a Common InterfacePrior works have used an assortment of sensors, but none have

proposed a common interface specifically for making energy dataavailable to software in a portable manner. Tools like PAPI are use-ful in some cases, but do not present data in a consistent format andinstead just provide direct access to the hardware sensors. Thus,PAPI and similar low-level tools require making application codechanges to support new power/energy data sources [43]. This re-quirement might be reasonable for the HPC domain it is designedfor, but fast becoming impractical for software like mobile appli-cations that are deployed on a wide variety of continually evolvingsystems. In POET, the authors created a primitive interface thatwas internal to their tool in an attempt to access energy data in amore portable manner than had been done previously [20]. POETis representative of many self-adaptive systems in that it is not de-signed to report energy usage, but simply use that data internally.Such systems do not expose implementation properties like refresh

interval, precision, or exclusiveness, nor do they enable sensiblebindings to other programming languages. Additionally, their im-plementations do not manage practical concerns like counter over-

flows or preservation of error codes.As software matures, its shelf life increases. That software will

continue to be deployed on new hardware for years to come, withfew upfront guarantees about the hardware’s power/energy proper-ties or how it will expose such data. Additionally, it is infeasiblefor most software to manage the challenges in correctly using pow-er/energy sensors for more than a handful of data sources. Muchof the information needed to effectively use power/energy sensorslike the access restrictions and operating system abstractions arenot important to the software that needs the data – they are periph-eral concerns. An interface can hide these details while exposingimportant properties in a common manner, like the actual energyvalues, the refresh interval, and the sensor’s precision, while requir-ing only a few lines of platform-independent code. We address thechallenges described in Section 2.1 and aforementioned problemsin prior work with EnergyMon, a portable interface for accessingenergy data in-situ that is independent of the data source. It can eas-ily be used by current and future power and energy-aware softwarewithout the need to change code for different deployment scenariosor even know the available sensors in advance.

3. DESIGN AND IMPLEMENTATIONS

3.1 Interface DesignThe first important design decision is which data type to expose

in a common interface – we choose energy. Unlike power, energy isnot explicitly a function of time and can be recorded cumulatively,simplifying the interface. With an energy provider that records totalenergy consumed since some time τ = 0, a power-aware applica-tion can simply record energy E at the beginning and end of a timeinterval and compute the average power as ∆E/∆τ. In this way, theinterface easily supports applications interested in energy or power.

Next, a common interface can expose energy metrics in a stan-dard and sufficiently precise unit of measurement at a large enough

data length to avoid overflow. Applications therefore do not need totrack various unit types and do conversions. A deceptively simplebut important insight is not our choice of units or data length, butrather that counter overflow is one of the diverse sensor propertiesthat applications should not have to worry about. We choose micro-joules ( µJ) as 64-bit unsigned integers2, which are precise enoughfor the use cases we anticipate and avoid the need for floating pointdata types. In our experience, modern sensors are too impreciseand models too inaccurate to justify smaller units.

The energymon C interface defines a struct that contains sevenfunction pointers and a state variable:• finit: Initialize the energy monitor.• fread: Get the cumulative energy in microjoules.• ffinish: Destroy the energy monitor.• fsource: Get the name for the energy monitoring source.• finterval: Get the refresh interval in microseconds.• fprecision: Get the best possible precision in microjoules.• fexclusive: Get if exclusive access is required.• state: Pointer to a struct that the implementation uses to

maintain internal state, e.g., file descriptors or thread data.This interface exposes some of the diverse properties described pre-viously, like refresh interval and sensor precision, while hidingother properties that are not important to most software, like theunderlying interfaces, device protocols, and data formats.

A user typically calls energymon_get_default provided bythe energymon-default interface to populate an energymon struct.If the implementation is known in advance, its getter function canbe called directly. The default interface enables maximum portabil-ity since application code does not require any modification whenchanging data sources. Using the function pointers in the energy-

mon struct provides portability for all other operations. The deci-sion to use function pointers instead of explicitly declaring com-mon header functions was made for practical reasons – in C, onlyone implementation of an interface can be implemented in a run-time. Reducing the number of common header functions min-imizes the need for conditionally including extra wrapper func-tions at compile time (energymon_get_default is the only one).Therefore, implementations conditionally include the default get-ter function, allowing multiple EnergyMon implementations to beused simultaneously when there are multiple power/energy datasources known in advance.

EnergyMon implementations are initialized by calling the finit

function pointer. If the implementation reads from a power sensor,finit starts a separate thread to poll the sensor at its refresh intervaland update the cumulative energy value after each sensor reading.The application reads from the energy monitor by invoking fread.For any time τ, where τ = 0 is the energy monitor’s initialization,the following invariants hold for energy readings E(τ):

∀τ ≥ 0 τi ≤ τ j =⇒ 0 ≤ E(τi) ≤ E(τ j) (1)

τ = 0 6 =⇒ E(τ) = 0 (2)

Eqn. 1 states that for any time at or after initialization, energy isalways non-negative and monotonically increasing. The only ex-ception should be in case of a sensor read failure – in C, a 0 valueis returned and errno set appropriately; abstractions in other lan-guages may use their own error handling mechanisms, like excep-tions. Eqn. 2 declares that the energy counter does not have to beginat 0 µJ. This flexibility facilitates sharing energy data with multi-ple applications and avoids the need to reset hardware counters,which is often a privileged operation. When the energy monitoris no longer needed, ffinish is called to cleanup resources like files

2At 100 W of power, it would take about 5,850 years to overflow.

or threads. The following example of the EnergyMon C interfacedemonstrates computing the average power of a worker function:

1 energymon em;

2 uint64_t start_uj , end_uj, start_usec , end_usec;

3

4 // get the energymon instance and initialize

5 energymon_get_default(&em);

6 em.finit(&em);

7

8 // get start time/energy

9 start_usec = gettime_us(); // e.g. wrap clock_gettime

10 start_uj = em.fread(&em);

11

12 // application -specific processing

13 do_work();

14

15 // get end time/energy

16 end_usec = gettime_us();

17 end_uj = em.fread(&em);

18

19 printf("Average power of do_work() in Watts: %f\n",

20 (end_uj-start_uj) / (double) (end_usec-start_usec));

21

22 // destroy the instance

23 em.ffinish(&em);

Listing 1: EnergyMon C example.

Other functions provide additional information about the imple-mentation that software can use to make runtime decisions. Forexample, applications can use the name provided by fsource fordebugging or logging. finterval can be used to determine a lowerbound on sleep time for polling the energy monitor at regular in-tervals. fprecision might inform a self-adaptive system how muchnoise to expect in power/energy data. fexclusive could be used indeciding to share energy data with other software components.

3.2 ImplementationsWe provide EnergyMon implementations for all the data sources

detailed in Table 1, which access various power and energy sensors,both embedded and external. The table describes their differencesin more detail. While not strictly a requirement, the interface is bestleveraged when the underlying energy source makes data availableto userspace. This allows sandboxed or other unprivileged applica-tions to measure their own behavior, or even to adjust their behaviorat runtime, e.g., to meet power cap requirements.

Some systems expose power or energy data for multiple sources.For example, the Intel MSR provides energy data for core and un-core components, as well as DRAM. Both the msr and rapl Energy-Mon implementations use the MSR as their data source. Similarly,the ARM big.LITTLE system used in this paper exposes powerdata for the SoC’s big cluster, LITTLE cluster, GPU, and DRAM.

The osp, osp-polling, and wattsup implementations read fromexternal sensors. The first two read from an ODROID Smart Powermeter [32] – osp reads energy data in Watt-hours, accurate to threedecimal places; osp-polling polls the sensor’s power readings inWatts, also accurate to three decimal places. The polling imple-mentation provides more accurate energy data given that Watt-hoursare so imprecise (1 Wh = 3600 J). The third implementation readsfrom a WattsUp? power meter, which provides power in deciwattsat coarse-grained one second intervals [42].

The shmem implementation reads from a shared memory loca-tion. Sensors that require exclusive access and/or elevated privi-leges are ideal candidates to run in separate processes and exposetheir data to multiple unprivileged applications over shared mem-ory. This is especially true for external meters, so we include sharedmemory providers for the osp-polling and wattsup implementa-tions. The dummy implementation is used when no other sourcesare available.

3.3 Bindings and AbstractionsCurrent EnergyMon implementations are written in C, but we

also provide interfaces in Java and Rust. Additionally, we makebindings and abstractions over the energymon-default C interfaceavailable for those languages. Bindings provide as close to directaccess to the underlying interfaces and implementations as possi-ble. Abstractions provide the safety guarantees these languagesdemand and the RAII3 idioms they commonly use.

In Java, we provide the EnergyMon interface, which implemen-tations written in pure Java may implement. Its methods throw ex-ceptions in error cases. The DefaultEnergyMon abstraction man-ages a JNI boundary, encapsulates pointers to heap allocations, andcleans up automatically. Users may also safely destroy an instancethemselves to immediately clean up resources, which might includebackground threads, if they do not wish to wait for garbage collec-tion. For example, to use the default Java abstraction:

1 // get the EnergyMon instance and initialize

2 EnergyMon em = DefaultEnergyMon.create();

3

4 // get start time/energy

5 long startMs = System.currentTimeMillis();

6 long startUj = em.readTotal();

7

8 // application -specific processing

9 doWork();

10

11 // get end time/energy

12 long endMs = System.currentTimeMillis();

13 long endUj = em.readTotal();

14

15 System.out.println("Average power of doWork() in Watts: "

16 + (endUj - startUj) / (1000.0 * (endMs - startMs)));

17

18 // destroy the instance (optional , but recommended)

19 em.finish();

Listing 2: EnergyMon Java interface and abstraction.

In Rust, we provide the EnergyMonitor trait where functionsthat are allowed to fail return a Result. EnergyMon implementa-tions written in Rust may implement this trait. The default Ener-

gyMon abstraction encapsulates the struct bindings and preventsaccidental or malicious destruction of an instance. For example, touse the default Rust abstraction:

1 // get the EnergyMon instance and initialize

2 // EnergyMon implements the EnergyMonitor trait

3 let em: EnergyMon = EnergyMon::new().unwrap();

4

5 // get start time/energy

6 let start_time: SystemTime = SystemTime::now();

7 let start_uj: u64 = em.read_uj().unwrap();

8

9 // application -specific processing

10 do_work();

11

12 // get end time/energy

13 let end_time: SystemTime = SystemTime::now();

14 let end_uj: u64 = em.read_uj().unwrap();

15 let duration: Duration = end_time.duration_since(

16 start_time).unwrap();

17

18 println!("Average power of do_work() in Watts: {}",

19 (end_uj - start_uj) as f64 /

20 (duration.as_secs() * 1000000 +

21 duration.subsec_nanos() as u64 / 1000) as f64);

22

23 // instance dropped automatically

24 // (when it falls out of scope or is consumed)

Listing 3: EnergyMon Rust trait and abstraction.

3Resource Acquisition is Initialization

4. EXPERIMENTAL DESIGN

4.1 Evaluation PlatformsWe use three very different hardware systems for our analysis.

The first is a Lenovo Thinkpad X1 Carbon laptop (3rd gen) withan Intel i7-5600U dual-core processor with Hyperthreading [11],running Ubuntu 15.10 with Linux kernel 4.2.0. The second is aHardkernel ODROID-XU3 mobile development platform with anExynos5 Octa 5422 SoC with quad core ARM Cortex-A15 “big”and Cortex-A7 “LITTLE” clusters [38]. The ODROID runs ei-ther Ubuntu 14.04 LTS with Hardkernel’s modified Linux kernel3.10.58+ or Android 4.4 “KitKat”, depending on the case study.The third system is a Sony VAIO SVT11226CXB tablet with adual-core Intel Haswell mobile processor with Hyperthreading [35].It runs Ubuntu 14.04 LTS with Linux kernel 3.13.0. Prior work hasshown that the Haswell processor and the Exynos big.LITTLE SoCexhibit contrasting performance/energy behavior [18].

4.2 Case StudiesEvaluating and exploiting performance and power tradeoffs are

common research topics, particularly in the embedded and mo-bile systems domain. Our first case study demonstrates diversityin both application and system performance/power tradeoffs, moti-vating the need for energy awareness in applications. We capturecoarse-grained timing and energy behavior for two distinct, unmod-ified applications using the Vaio and the ODROID, both runningLinux. It is common for engineers to use external instrumentationwhen evaluating software behavior on different systems, so we usea WattsUp? PRO meter with the wattsup EnergyMon implemen-tation on the Vaio, and an ODROID Smart Power meter with theosp-polling implementation on the ODROID. Since video encod-ing is a common task for embedded systems like mobile phones andtablets that have on-board cameras, we use a compute-bound paral-lel video encoder for the first application [4]. We use the STREAMbenchmark as the second example to represent memory-intensiveapplications [28].

The second case study profiles Servo, Mozilla’s parallel webbrowsing engine written in Rust [3, 27], at a fine-grained level. Thisexperiment uses the Thinkpad and the ODROID. The Thinkpadruns Linux and uses the msr EnergyMon implementation to readfrom the Intel MSR [35]. The ODROID now runs Android anduses the odroid-ioctl implementation to poll embedded TI INA-231power sensors [21]. We use a real, industrial-strength application todemonstrate that EnergyMon provides in-situ runtime energy dataon different hardware and software platforms suitable for profilingin a practical setting.

Our third case study returns to the parallel video encoding appli-cation used in the first experiment [4], but now uses a version thatwas previously modified to configure resource allocation at runtimeto obey soft power constraints. Again we use the Vaio tablet and theODROID, both running Linux. The modified application’s feed-back controller was originally designed for the systems’ embeddedsensors, but we substitute the energymon-default interface and useexternal power meters. This provides an additional challenge andfurther demonstrates EnergyMon’s utility and portability. We onceagain connect the Vaio to an external WattsUp? PRO power me-ter [42] and the ODROID to an external ODROID Smart Powermeter [32]. Because these meters require elevated privileges andexclusive access, we now launch the wattsup and osp-polling En-ergyMon implementations in a separate process and expose energydata to the application using shared memory. This makes the en-ergy data available to any application that wants it, which we ac-cess with the shmem EnergyMon implementation during applica-

0 0.25 0.5 0.75 1.00

0.25

0.5

0.75

1.0

Per f ormance

Pow

er

Idle All

(a) Intel Haswell (wattsup)

0 0.25 0.5 0.75 1.00

0.25

0.5

0.75

1.0

Per f ormance

Pow

er

Idle big LITTLE

(b) ARM big.LITTLE (osp-polling)

Figure 1: Performance/power tradeoffs using DVFS and core allo-cation for a parallel video encoding application.

tion runtime. This experiment not only demonstrates EnergyMon’spotential for self-adaptive applications, but demonstrates its flexi-bility and portability by using sensors the self-adapting controllerwas not originally designed for.

In summary, our case studies use Linux and Android and run onthree different hardware platforms – a tablet with an Intel Haswellprocessor, an ARM big.LITTLE development platform, and a lap-top with an Intel i7 processor. We use four distinct power/energydata sources – the Intel MSR, embedded TI INA-231 power sen-sors, an external WattsUp? PRO meter, and an external ODROIDSmart Power meter.

5. EXPERIMENTAL EVALUATIONThis section presents our analysis of EnergyMon with case stud-

ies that motivate the importance of energy awareness in softwareand demonstrate EnergyMon’s utility. We also analyze Energy-Mon’s runtime overhead, then discuss limitations and future work.

5.1 Performance/Power TradeoffsOur first case study demonstrates diversity in performance/power

tradeoffs for systems and applications, motivating the importanceof energy awareness in software. To properly manage system re-source allocation, engineers must understand their application’s be-havior, even if only at a coarse-grained level. This is especiallytrue for applications that run on energy-constrained platforms likeembedded and mobile systems. Software exhibits different perfor-mance/power tradeoffs depending on the system it is executed on,and behavior can even vary dramatically for different applicationsrunning on the same system. Performance/power tradeoffs are a

function of both the application and the system. We first demon-strate tradeoff diversity between systems with a parallel video en-coding application [4]. We then show diversity across applicationson the same system by comparing these results with those producedby the STREAM benchmark, which represents memory-intensiveapplications [28].

We connect the tablet with the Intel Haswell mobile processorand the ARM big.LITTLE development system to external WattsUp?PRO and ODROID Smart Power meters, respectively. We allocateunique combinations of DVFS frequency and core assignment –44 configurations for the Intel Haswell and 128 configurations forthe ARM big.LITTLE. We record the total application runtime andsystem energy consumption for each configuration, which we useto compute normalized average performance and power values.

Figure 1 is the resulting tradeoff space for the video encoder, nor-malized to the maximum performance and power achieved on eachsystem. System idle power is included for reference. The IntelHaswell has a mostly linear tradeoff space, with maximum perfor-

0 0.25 0.5 0.75 1.00

0.25

0.5

0.75

1.0

Per f ormance

Pow

erIdle All

(a) Intel Haswell (wattsup)

0 0.25 0.5 0.75 1.00

0.25

0.5

0.75

1.0

Per f ormance

Pow

er

Idle big LITTLE

(b) ARM big.LITTLE (osp-polling)

Figure 2: Performance/power tradeoffs using DVFS and core allo-cation for a parallel memory-intensive application.

mance about 8× the minimum, and maximum power slightly lessthan 2× the minimum. The ARM big.LITTLE’s tradeoff space ismuch richer and noticeably more convex, with a performance andpower range much greater than the Intel Haswell. Its maximum per-formance is nearly 70× greater than the minimum, and maximumpower is more than 5× the minimum. The shapes of the tradeoffspaces for the video encoding application are similar to those ofother parallel compute-bound applications we evaluated on thesesystems.

Figure 2 shows how different the tradeoffs are for memory-intensiveapplications compared to the video encoder’s in Figure 1. TheIntel Haswell no longer has any configurations between the per-formance/power extremes. Without this knowledge, a developeror user might naively assume that mid-range resource allocationswould provide mid-range performance and power consumption. TheARM big.LITTLE still offers configurations that cover the range ofperformance/power values, but a performance wall is eventuallyreached as more resources are allocated. In fact, many configura-tions that were high-performance/high-power for the video encoderare still high-power but actually have lower performance than someconfigurations that require fewer resources and less power. Failureto recognize these differences may result in inefficient or even in-adequate system resource allocations for applications.

The specific tradeoffs for the systems and applications we ex-amine are not the important conclusions in this case study. Whatis important is that power and energy-aware applications must rec-ognize and manage these behavioral characteristics to make intel-ligent runtime decisions. This diversity in application and system

behavior motivates the need for energy awareness in software – a

capability that EnergyMon facilitates.

5.2 ServoThis case study uses Servo, Mozilla’s parallel web browsing en-

gine. We add energy monitoring to Servo’s existing fine-grainedtime profiling interface and add a background profiler category

called ApplicationHeartbeat to record runtime power behavior. Weprofile Servo on the Thinkpad with an Intel i7 processor runningLinux, and the ODROID with an ARM big.LITTLE SoC runningAndroid. We capture energy readings for each platform’s proces-sors rather than using external equipment. The experiment loadsServo, fetches the page mozilla.org from the remote server, pro-cesses the page, and displays it. We instruct Servo to use four lay-out threads on each evaluation system (the Intel i7 has four virtualcores, and each of the ARM big.LITTLE clusters has four cores).

Figures 3a and 3b break down by profiler category where timeand energy are spent within Servo while loading on the two plat-forms, averaged over four trials. Profiler category names are trimmed

Applica

tion

HC

ompos

itin

g

Layo

utD

ispL

i

Layo

utG

ener

aL

ayo

utM

ain

Layo

utP

ara

ll

Layo

utP

erfo

r

Layo

utR

esty

l

Layo

utS

tyle

RPain

ting

Pain

tingP

erT

Scr

iptC

onst

e

Scr

iptD

ocum

eScr

iptE

vent

Scr

iptI

mage

C

Scr

iptN

etw

orScr

iptR

esiz

eScr

iptS

etV

ie

Scr

iptU

pdate

0

1000

2000

3000

4000

5000

6000

7000

Tim

e(m

s)

Time

Energy

0

20

40

60

80

En

erg

y(J

ou

les)

(a) Intel i7 on Linux (msr)

Applica

tion

HC

ompos

itin

g

Layo

utD

ispL

i

Layo

utG

ener

aL

ayo

utM

ain

Layo

utP

ara

ll

Layo

utP

erfo

r

Layo

utR

esty

l

Layo

utS

tyle

RPain

ting

Pain

tingP

erT

Scr

iptC

onst

e

Scr

iptD

ocum

eScr

iptE

vent

Scr

iptI

mage

C

Scr

iptN

etw

or

Scr

iptR

esiz

e

Scr

iptS

etV

ie

Scr

iptU

pdate

0

5000

10000

15000

20000

25000

30000

Tim

e(m

s)

Time

Energy

0

20

40

60

80

100

120

140

En

erg

y(J

ou

les)

(b) ARM big.LITTLE on Android (odroid-ioctl)Figure 3: Cumulative time and energy consumption in Servo.

to save space, and unused categories are not shown. Engineers usetiming and energy data to decide where to focus their optimizationefforts. Developers will recognize that tasks running in parallel,like PaintingPerTile, record their own elapsed time which results intotal time values that exceed actual runtime. Energy is measuredfor shared system components, so some energy consumption is as-signed to multiple profiler categories and is therefore counted morethan once (the sum of the energy values exceeds the actual energyconsumed). More advanced profiling and analysis techniques be-yond the scope of this paper are needed to better assign time andenergy consumption to parallel tasks. ApplicationHeartbeat pro-vides the true wall clock time and total energy consumption for theexecution. Layout operations require a significant portion of thetotal time and energy on the Intel i7 in Linux, but painting con-sumes a larger percentage of the runtime on the ARM big.LITTLEin Android. This means developers need to concentrate their ef-forts in different places depending on the system they are trying tooptimize for.

Figures 4a and 4b present the time series for a single execution,overlayed with system power derived from ApplicationHeartbeat’senergy readings. The ApplicationHeartbeat polling interval is lim-ited by the refresh rate of the sensors underlying the EnergyMonimplementation, as exposed by the finterval function, hence themore coarse-grained power data on the ARM big.LITTLE system(its power sensors refresh about 4× per second). The Intel i7’s MSRrefreshes every 1 ms, but we limit the profiler’s polling interval to50 ms to avoid unnecessary overhead.

The LayoutPerform profiler category is an umbrella event for alllayout operations. LayoutStyleRecalc determines which CSS styles

0 1000 2000 3000 4000 5000

Time (ms)

ApplicationHeart

Compositing

LayoutDispListBu

LayoutGeneratedC

LayoutMain

LayoutParallelWa

LayoutPerform

LayoutRestyleDam

LayoutStyleRecal

Painting

PaintingPerTile

ScriptConstellat

ScriptDocumentEv

ScriptEvent

ScriptImageCache

ScriptNetworkEve

ScriptResize

ScriptSetViewpor

ScriptUpdateRepl

0

5

10

15

20

Pow

er

(Watt

s)

(a) Intel i7 on Linux (msr)

0 2000 4000 6000 8000 10000 12000

Time (ms)

ApplicationHeart

Compositing

LayoutDispListBu

LayoutGeneratedC

LayoutMain

LayoutParallelWa

LayoutPerform

LayoutRestyleDam

LayoutStyleRecal

Painting

PaintingPerTile

ScriptConstellat

ScriptDocumentEv

ScriptEvent

ScriptImageCache

ScriptNetworkEve

ScriptResize

ScriptSetViewpor

ScriptUpdateRepl

0

2

4

6

8

Pow

er

(Watt

s)

(b) ARM big.LITTLE on Android (odroid-ioctl)Figure 4: Timing and power behavior while loading mozilla.org in Servo.

apply to each of the nodes in the Document Object Model (DOM)tree and creates a structure that layout will use to determine elementpositioning. This is a time-consuming operation given that it musttraverse the DOM tree. LayoutMain then determines where to posi-tion elements when rendering on the screen. The time series makesit clear that layout tasks, especially LayoutStyleRecalc, consumemore power than average on the Intel i7. The power data capturedon the ARM big.LITTLE in Android is more coarse-grained, butaccounting for the delays also indicates the same trend.

On ARM, there is a large power spike about halfway through theexecution – something we saw in all of our trials. The current pro-filing does not point to an obvious reason for this, indicating thatthe application developers should investigate further. More impor-tantly, this behavior would not be detected by time profiling alone,

yet is critical on power and energy-constrained systems.

Despite the differences in the two platforms, we are able to cap-ture useful profiling energy data from both using the common En-ergyMon interface. This energy profiling capability is now publiclyavailable as part of Servo via the energy-profiling feature.

5.3 Self-Adaptive ApplicationThis experiment uses an energy-aware parallel video encoding

application that adjusts its resource usage at runtime to meet softpower constraints [19]. Given a power target and set of config-urable system resources, it adapts to meet the power target whilemaximizing performance. We substitute EnergyMon for the con-troller’s custom energy monitoring code. To further challenge En-ergyMon and demonstrate its versatility, we again use external in-struments instead of the platforms’ embedded sensors that the feed-back controller originally intended to use. The experiment is par-

0.25

0.50

0.75

1.0

Perf

orm

ance

(Nor

mal

ized

)Intel Haswell (wattsup) ARM big.LITTLE (osp-polling)

0 500 1000 15000.500.75

1.01.251.50

time [frame]

Pow

er(N

orm

aliz

ed)

Figure 5: Meeting soft power constraints with an energy-awarevideo encoder using EnergyMon and external power meters.

ticularly challenging because of the relatively slow refresh rate,coarse-grained accuracy, and additional I/O overhead of commu-nicating with the devices over USB. We select a window period of50 frames – the work interval at which the application adjusts itsresource usage. For each system, we set the power target to be themean of the minimum and maximum processing power. We thenlaunch the application with an input that is the combination of threevideos with distinct levels of encoding difficulty.

Figure 5 is a time series of the resulting behavior. The top por-tion of the figure is the window performance (frames encoded persecond), normalized to highest for each system; the bottom portionshows the window power, normalized to the target. The verticallines at frames 500 and 1000 indicate the boundary between the in-put video’s phases. The system power hovers around the target asthe application adjusts resource usage while the performance fluc-tuates depending on the level of encoding difficulty for each frame.

Maintaining the desired power on the Intel Haswell is more dif-ficult than on the ARM big.LITTLE. The slower refresh rate andlower precision of the WattsUp? power meter, compounded bythe Haswell’s faster processing speed and the variable difficulty ofencoding the input video (even within a single phase) make thetask especially challenging. During the first window period (50frames), the application observes system behavior, then makes itsfirst resource allocation adjustment. For frames after the first periodof resource adjustment (frame 100), the mean window power perframe is 0.14% above the target on the Intel Haswell and 0.027%below the target on the ARM big.LITTLE, with 4.4% and 2.0%coefficient of variation, respectively. Of these frames, 44.6% onthe Haswell and 43.4% on the big.LITTLE had an average win-dow power above the target. This is expected when meeting softpower targets for an application that exhibits as much variabilityas a video encoder [20]. The application could be tuned further tokeep more frames below the power target, but that is beyond thescope of this work. What is important for this case study is thatEnergyMon successfully provided the necessary energy data to theapplication’s feedback controller. Despite the challenges, Energy-

Mon’s portable interface allows the application to use data from

external power meters it was not originally designed for to meet its

power constraints.

5.4 Overhead AnalysisRuntime overhead is an important consideration when collecting

power/energy data, whether it be for profiling, a feedback controlsystem, or something else. We took simple in-situ timing measure-ments for the finit, fread, and ffinish functions on current Energy-Mon implementations and averaged the results of 100 trials. We

dummymsr

odroid

odroid-ioctl osp

osp-polling

rapl

shmemwatt

sup1 ns

1 µs

1 ms

1 sec

Func

tion

Lat

ency

f init f read f f inish

Figure 6: Average function overhead (log scale).

have not attempted to optimize our implementations’ performancebeyond the obvious design decisions required to achieve accurateresults, like caching file descriptors as part of the state variable (seeSection 3.1).

Figure 6 shows the average latency for these three functions –note the log scale. The odroid, odroid-ioctl, osp, and osp-polling

implementations were tested on the ODROID, the rest on the Thinkpad.Initialization and destruction of energy monitors are the most time-consuming tasks (finit and ffinish), but only need to be done once.Implementations that read from external devices must perform I/Ocommunications with the devices and may need to wait while theyreset internally. For example, the wattsup implementation mustsleep for a whole second after clearing the device memory beforeit starts capturing, so it took an average of about 1.5 seconds tocompletely initialize. On the other hand, the msr and rapl im-plementations initialized in about 50 µs. The odroid implementa-tion took 1.6 ms since it scans the sysfs filesystem for the sensors;odroid-ioctl took 384 µs to open the four device files and enable thesensors. If the overhead of finit and ffinish truly matter to an ap-plication, the energy monitor can be run in a background processand expose data using shared memory. Applications can then readenergy data using the shmem implementation, like in Section 5.3,which initialized and finished in 9.0 µs and 2.3 µs, respectively.

The fread function provides the core functionality and is natu-rally executed the most. The msr implementation took less than1 µs on average and rapl took 15 µs. The osp implementation readsfrom an external ODROID Smart Power meter over USB, whichcaused relatively high latency – about 12 ms. However, the refreshinterval of the device is 200 ms, so the implementation is not veryuseful for applications that need to poll more frequently. Imple-mentations that read from power sensors have background threadsto poll the sensors, and account for the I/O and runtime latencywhen computing energy from power. In these cases, reading theenergy data from an application only involves accessing 8 bytes ofmemory. Their response times were typically around 1 µs, at whichpoint the precision, refresh rate, and overhead of reading the systemclock affects the accuracy of the measurement.

5.5 Limitations and Future WorkAs with any power/energy monitoring, whether performed in-

situ or externally, results are limited by the precision, accuracy, andrefresh rate of the sensors. A sensor that only updates once per sec-ond may not be as useful as one that updates more frequently. Incases of relatively slow refresh intervals, tasks sometimes completetoo quickly to capture an accurate change in energy values. Mostof the time no change in energy will be recorded, but occasionallya task execution will overlap with a sensor refresh and record aninaccurately large change in energy for a short-lived task. With astatistically large enough sampling, the total energy recorded forrelatively short-lived tasks will average to reasonably accurate val-ues. Servo’s PaintingPerTile profiler category in Figures 3 and 4is a good example of this behavior. The most informative results

we observed were captured using the Intel MSR, which refreshesat millisecond intervals.

Some power/energy sensors require exclusive access, particu-larly external meters. If multiple parties are interested in using thesensor simultaneously, a reader can run in a separate process andexpose the data over shared memory or other IPC mechanisms. Forexample, we wrote shared memory providers for the osp-polling

and wattsup EnergyMon implementations. Applications then justlink with the shmem implementation.

Automatic discovery of power/energy sensors is an importantnext step for hardware and operating systems designers to address.A standard operating system interface would offer greater flexibil-ity to power and energy-aware applications. Advances in operatingsystem support would not eliminate the need for a portable appli-cation interface like EnergyMon, but rather expand its utility.

Unfortunately, not all systems have power/energy sensors or areconnected to external meters. EnergyMon implementations can in-stead use models based on other hardware counters or sensors toprovide energy estimates. There is prior work on building pow-er/energy models based on other hardware counters, but is beyondthe scope of this work [8, 26, 34, 39, 46]. However, future workincludes building implementations that can interpret models in acommon format, perhaps using tools like PAPI [5] to read perfor-mance counters as needed to drive the model.

6. CONCLUSIONThis paper describes the challenges arising from the diversity in

power and energy data sources, motivating the need for a commoninterface to expose energy data to software. In response, we pro-pose EnergyMon, a portable interface that is independent of under-lying power/energy sensors. We demonstrate the interface’s flexi-bility and practicality with three use cases. We first show diversityin performance/power tradeoffs across platforms, and for applica-tions running on the same platform, motivating the need for en-ergy awareness in software. Next, we instrument Servo, Mozilla’sparallel web browsing engine, with energy profiling and describethe insight it provides. This feature is now publicly available inServo. We then substitute EnergyMon for an energy-aware videoencoder’s custom energy monitoring code and show that it contin-ues to meet imposed power constraints, even using different sensorsthan it was originally designed for. Our experiments use both in-ternal and external power and energy sensors with widely varyingproperties on platforms with different, sometimes contrasting, per-formance and energy characteristics. We release the EnergyMoninterface, implementations, Java and Rust bindings, and other util-ities as open source.

References

[1] W. Baek and T. Chilimbi. “Green: A Framework for Sup-porting Energy-Conscious Programming using ControlledApproximation”. In: PLDI. 2010.

[2] A. Banerjee, L. K. Chong, S. Chattopadhyay, and A. Roy-choudhury. “Detecting Energy Bugs and Hotspots in Mo-bile Apps”. In: FSE. 2014.

[3] L. Bergstrom, B. Anderson, M. Goregaokar, J. Matthews,K. McAllister, J. Moffitt, and S. Sapin. “Engineering theServo Web Browser Engine using Rust”. In: ICSE. 2016.

[4] C. Bienia, S. Kumar, J. P. Singh, and K. Li. “The PARSECBenchmark Suite: Characterization and Architectural Im-plications”. In: PACT. 2008.

[5] S. Browne, J. Dongarra, N. Garner, G. Ho, and P. Mucci.“A Portable Programming Interface for Performance Eval-uation on Modern Processors”. In: Int. J. High Perform.

Comput. Appl. 14.3 (Aug. 2000), pp. 189–204.[6] B. Cheng, R. de Lemos, H. Giese, P. Inverardi, J. Magee,

J. Andersson, B. Becker, N. Bencomo, Y. Brun, B. Cu-kic, G. Di Marzo Serugendo, S. Dustdar, A. Finkelstein,C. Gacek, K. Geihs, V. Grassi, G. Karsai, H. Kienle, J.Kramer, M. Litoiu, S. Malek, R. Mirandola, H. Müller,S. Park, M. Shaw, M. Tichy, M. Tivoli, D. Weyns, and J.Whittle. “A Research Roadmap”. In: Software Engineer-

ing for Self-Adaptive Systems. 2009.[7] R. Cochran, C. Hankendi, A. K. Coskun, and S. Reda.

“Pack & Cap: adaptive DVFS and thread packing underpower caps”. In: MICRO. 2011.

[8] G. Contreras and M. Martonosi. “Power Prediction forIntel XScale R©Processors Using Performance MonitoringUnit Events”. In: ISLPED. 2005.

[9] Z. Cui, Y. Zhu, Y. Bao, and M. Chen. “A fine-grainedcomponent-level power measurement method”. In: IGCC.2011.

[10] H. David, E. Gorbatov, U. R. Hanebutte, R. Khanna, andC. Le. “RAPL: Memory Power Estimation and Capping”.In: ISLPED. 2010.

[11] A. Deval, A. Ananthakrishnan, and C. Forbell. “Powermanagement on 14 nm Intel Core-M processor”. In: Low-

Power and High-Speed Chips (COOL CHIPS XVIII), 2015

IEEE Symposium in. 2015, pp. 1–3.[12] J. Durango, M. Dellkrantz, M. Maggio, C. Klein, A. V. Pa-

padopoulos, F. Hernández-Rodriguez, E. Elmroth, and K.-E. Arzén. “Control-theoretical load-balancing for cloudapplications with brownout”. In: CDC. 2014.

[13] J. Flinn and M. Satyanarayanan. “PowerScope: a tool forprofiling the energy usage of mobile applications”. In: WM-

CSA. 1999.[14] J. Flinn and M. Satyanarayanan. “Energy-aware adapta-

tion for mobile applications”. In: SOSP. 1999.[15] HID API for Linux, Mac OS X, and Windows. http://

www.signal11.us/oss/hidapi/.[16] H. Hoffmann. “CoAdapt: Predictable Behavior for Accuracy-

aware Applications Running on Power-aware Systems”.In: ECRTS. 2014.

[17] H. Hoffmann. “JouleGuard: energy guarantees for approx-imate applications”. In: SOSP. 2015.

[18] C. Imes and H. Hoffmann. “Minimizing Energy UnderPerformance Constraints on Embedded Platforms: ResourceAllocation Heuristics for Homogeneous and Single-ISAHeterogeneous Multi-Cores”. In: EWiLi. 2014.

[19] C. Imes and H. Hoffmann. “Bard: A Unified Frameworkfor Managing Soft Timing and Power Constraints”. In:SAMOS. 2016.

[20] C. Imes, D. H. K. Kim, M. Maggio, and H. Hoffmann.“POET: A Portable Approach to Minimizing Energy Un-der Soft Real-time Constraints”. In: RTAS. 2015.

[21] T. Instruments. http://www.ti.com/product/ina231.[22] M. Kim, M.-O. Stehr, C. Talcott, N. Dutt, and N. Venkata-

subramanian. “xTune: A Formal Methodology for Cross-layer Tuning of Mobile Embedded Systems”. In: ACM

Trans. Embed. Comput. Syst. 11.4 (Jan. 2013).[23] C. Klein, M. Maggio, K.-E. Årzén, and F. Hernández-

Rodriguez. “Brownout: Building more robust cloud ap-plications”. In: ICSE. 2014.

[24] J. Kramer and J. Magee. “Self-Managed Systems: an Ar-chitectural Challenge”. In: FOSE. 2007.

[25] J. Laros, P. Pokorny, and D. DeBonis. “PowerInsight -A commodity power measurement capability”. In: IGCC.2013.

[26] B. C. Lee and D. M. Brooks. “Accurate and Efficient Re-gression Modeling for Microarchitectural Performance andPower Prediction”. In: ASPLOS. 2006.

[27] N. D. Matsakis and F. S. Klock II. “The Rust Language”.In: HILT. 2014.

[28] J. D. McCalpin. “Memory Bandwidth and Machine Bal-ance in Current High Performance Computers”. In: IEEE

TCCA Newsletter (1995).[29] D. McIntire, T. Stathopoulos, and W. Kaiser. “Etop: Sen-

sor Network Application Energy Profiling on the LEAP2Platform”. In: IPSN. 2007.

[30] G. Metri, A. Agrawal, R. Peri, M. Brockmeyer, and W.Shi. “A simplistic way for power profiling of mobile de-vices”. In: ICEAC. 2012.

[31] S. Mohapatra, R. Cornea, H. Oh, K. Lee, M. Kim, N. Dutt,R. Gupta, A. Nicolau, S. Shukla, and N. Venkatasubra-manian. “A cross-layer approach for power-performanceoptimization in distributed mobile systems”. In: IPDPS.2005.

[32] ODROID Smart Power. http : / / ameridroid . com /products/smart-power.

[33] A. Pathak, Y. C. Hu, and M. Zhang. “Where is the EnergySpent Inside My App?: Fine Grained Energy Accountingon Smartphones with Eprof”. In: EuroSys. 2012.

[34] A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y.-M. Wang.“Fine-grained Power Modeling for Smartphones Using Sys-tem Call Tracing”. In: EuroSys. 2011.

[35] E. Rotem, A. Naveh, D. R. amd Avinash Ananthakrish-nan, and E. Weissmann. “Power management architectureof the 2nd generation Intel Core microarchitecture, for-merly codenamed Sandy Bridge”. In: Hot Chips. 2011.

[36] M. Sabharwal, G. Metri, C. Huang, and A. Agrawal. “To-wards fine grain power profiling tools for SoC based mo-bile devices”. In: ICEAC. 2013.

[37] M. Salehie and L. Tahvildari. “Self-adaptive software: Land-scape and research challenges”. In: ACM Trans. Auton.

Adapt. Syst. 4.2 (2009).[38] Y. Shin, K. Shin, P. Kenkare, R. Kashyap, H.-J. Lee, D.

Seo, B. Millar, Y. Kwon, R. Iyengar, M.-S. Kim, A. Chowd-hury, S.-I. Bae, I. Hon, W. Jeong, A. Lindner, U. Cho, K.Hawkins, J. Son, and S. Hwang. “28nm High-K Metal-Gate Heterogeneous Quad-Core CPUs for High-Performanceand Energy-Efficient Mobile Application Processor”. In:ISSCC. 2013.

[39] K. Singh, M. Bhadauria, and S. A. McKee. “Real TimePower Estimation and Thread Scheduling via PerformanceCounters”. In: SIGARCH Comput. Archit. News 37.2 (July2009), pp. 46–55.

[40] J. Sorber, A. Kostadinov, M. Garber, M. Brennan, M. D.Corner, and E. D. Berger. “Eon: a language and runtimesystem for perpetual systems”. In: SenSys. 2007.

[41] V. Vardhan, W. Yuan, A. F. H. III, S. V. Adve, R. Kravets,K. Nahrstedt, D. G. Sachs, and D. L. Jones. “GRACE-2:integrating fine-grained application adaptation with globaladaptation for saving energy”. In: IJES 4.2 (2009).

[42] WattsUp .Net Meter. http://www.wattsupmeters.com/.

[43] V. Weaver, M. Johnson, K. Kasichayanula, J. Ralph, P.Luszczek, D. Terpstra, and S. Moore. “Measuring Energyand Power with PAPI”. In: ICPPW. 2012.

[44] W. Yuan and K. Nahrstedt. “Energy-efficient soft real-timeCPU scheduling for mobile multimedia systems”. In: SOSP.2003.

[45] H. Zhang and H. Hoffmann. “Maximizing PerformanceUnder a Power Cap: A Comparison of Hardware, Soft-ware, and Hybrid Techniques”. In: ASPLOS. 2016.

[46] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z.M. Mao, and L. Yang. “Accurate Online Power Estima-tion and Automatic Battery Behavior Based Power ModelGeneration for Smartphones”. In: CODES/ISSS. 2010.