EnergAt: Fine-Grained Energy Attribution for Multi-Tenancy

In recent years, several tools have been developed to measure software energy consumption (e.g., [6, 12, 21, 25, 34, 52]). These tools have primarily focused on usability, accessibility, and the interpretability of their outputs, but they do not aim for fine-grained energy attribution. Specifically, they either assume that the measured application is not collocated with other tasks, treating the total energy consumption of the host machine as that of the target application, or they use coarse-grained energy attribution models at the process level [11, 52] and do not consider NUMA effects in case of multiple CPU sockets (§2).

NUMA = non-uniform memory access

We find that the lack of such accounting in fine-grained, software-centric attribution methodology [4] leads to more than 46.3% overestimation and 93.3% underestimation (Fig. 1), which could be detrimental for sustainable runtime operations.

For instance, as of the Sandy Bridge generation, Intel processors come with a built-in power meter, the Running Average Power Limit (RAPL) [48]. It provides an interface to the accumulated energy consumption of various components, e.g., CPU package and DRAM. Although its energy reporting is mainly based on kernel events [48], RAPL has been proven to be sufficiently accurate and can capture millisecond-level energy events [22, 29, 48].

Several recent tools have been developed to measure software energy consumption. Many of them focus on machine learning (ML) workloads, which are particularly energy-intensive [25, 45, 54]. To name a few, CodeCarbon [34] reports the energy usage of a program, measuring the consumption of CPU, DRAM, and GPU. It features a user-friendly API, a UI and exports interpretable results. Carbontracker [6] offers similar measurements and predicts the energy consumption of ML training based on a few epochs. Specifically built for ML applications, Experiment Impact Tracker (Impact Tracker) [25] collects energy measurements for both CPU and GPU, and allows users to generate environmental impact statements for their experiments. Another popular tool is Scaphandre [21] which has integrated support for power measurements in Kubernetes.

In this work, we demonstrate finegrained energy attribution of CPU and DRAM with coarse-grained measurements from Intel RAPL meter. CPU and DRAM are primary consumers of software energy.

Nowadays, applications are typically deployed in the cloud, where they are colocated with other tasks, sharing resources on the same host. Multi-tenancy creates “noisyneighbor” effects [15, 16], by which the performance of an application is interfered by its “neighbors”. In the presence of such interference, only the energy consumed by the target application should be accounted.

Image description:
Drastically different results from various tools on four microbenchmarks (Table 2). The bars below the (total) values are the attributed energies to the corresponding benchmark tasks by different tools. We highlight three observations: (1) existing methods can exhibit more than 46.3% overestimation and 93.3% underestimation of the attributed energy compared to the total values, (2) the total energy consumption measured by our fine-grained energy attribution model EnergAt matches that of the reference value, and (3) the dotted line illustrates that EnergAt is robust to the noisy-neighbor effect.

Although our proposed method demonstrates promising results, several limitations are crucial to be addressed in future work. First, the power modeling (Eg. 10 and 16) does not take into account other relavent factors, such as various I/O and caches [52]. Also, it only considers private memories, which results in lower energy attribution on the mem microbenchmark (Fig. 2).

The lack of secure and efficient interfaces between hardware and software severely inhibits energy measurement ( 2 ). For instance, reading RAPL requires manual timestamp alignment [22] and privileged permission for security [13]. Moreover, virtualization is a similar challenge as energy-related counters are generally not propagated to the virtualized applications. Consequently, most of the energy models for virtualized environments are predictive and treat user programs as black boxes [9, 17, 18, 32].