ConceptioArchivearXiv CS
arXiv CSopen access

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems

Unknown · 2026 · arxiv_cs
arXiv CS · Papers · License: Open Access · 2026
Open Source ↗Direct PDF ↓
clouddistributedcomputingparallelcomputing
distributed computing, parallel computing, cloud

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems Zhong Zheng

Michael E. Papka

Zhiling Lan

Department of Computer Science University of Illinois Chicago Chicago, USA [email protected]

Argonne National Laboratory University of Illinois Chicago Lemont, USA [email protected]

University of Illinois Chicago Argonne National Laboratory Chicago, USA [email protected]

arXiv:2604.17635v1 [cs.DC] 19 Apr 2026

Abstract Power-constrained HPC systems increasingly run heterogeneous CPU–GPU applications under strict cluster-wide power limits. Existing cluster-wide power management policies rely on fair-share or utilization heuristics and do not capture application-specific sensitivity to CPU and GPU power caps, leading to inefficient use of reclaimed power. We present EcoShift, a performance-aware cluster-wide power management framework. EcoShift combines online performance prediction with a dynamic-programming-based allocator to distribute reclaimed power across CPU–GPU applications for maximum average performance improvement. Through emulation-based evaluation on two heterogeneous Intel CPU and NVIDIA A100/H100 GPU platforms with diverse CPU– GPU workloads, EcoShift consistently outperforms state-of-the-art policies, achieving up to 6% average performance improvement while preserving the cluster-wide power constraint.

Keywords Heterogeneous Computing, Energy Efficiency ACM Reference Format: Zhong Zheng, Michael E. Papka, and Zhiling Lan. 2026. EcoShift: PerformanceAware Power Management for Power-Constrained Heterogeneous Systems. In . ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/nnnnnnn. nnnnnnn

1

Introduction

High-performance computing (HPC) drives progress across many scientific and engineering domains by enabling the solution of complex problems using large-scale computation, memory, storage, and networking resources. However, modern HPC systems face increasingly tight energy constraints as they approach the exascale era. Cluster-wide power capping has therefore been proposed as a practical approach, where systems are designed to draw power beyond the nominal budget while enforcing node-level power limits to respect a cluster-wide power constraint [28]. Mechanisms such as power capping [23], and dynamic voltage and frequency scaling 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. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Conference’17, Washington, DC, USA © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM https://doi.org/10.1145/nnnnnnn.nnnnnnn

(DVFS) [7] are widely used to enforce these limits, using interfaces such as Intel RAPL [8] and NVIDIA NVML [26]. In production HPC systems, power consumption varies significantly across applications, and it is rare for all workloads to simultaneously reach peak power. For instance, Cornelius et al. [6] analyze the Polaris supercomputer and report that applications consume, on average, only about 25% of the available GPU power. As a result, under a cluster-wide power budget enforced via uniform per-node caps, some applications may be power constrained, while others consistently draw substantially less than their allocated budget due to workload characteristics [28]. We define the gap between an application’s assigned power budget and its observed power draw as reclaimed power. This reclaimed power can potentially be pooled and redistributed to other applications to improve their performance without violating the cluster-wide power constraint. However, uniform distribution policies often break down because applications exhibit distinct power–performance relationships: the same additional power budget can yield negligible improvement for one application while significantly accelerating another [39]. Modern workloads increasingly leverage both CPUs and GPUs (hereafter heterogeneous applications, in contrast to CPU-only applications), including GPU-accelerated scientific codes and deep learning workloads. These applications are highly diverse in their resource usage: some are predominantly GPU-bound, while others remain CPU-bound due to control flow, synchronization, or frequent CPU–GPU data transfers [18, 22]. This diversity complicates cluster-wide power distribution because effective decisions must account for each application’s asymmetric sensitivity to CPU and GPU power caps and the diminishing returns of extra power. Although several prior studies have explored cluster-wide power distribution of reclaimed power [9, 31, 35, 36], most approaches either redistribute reclaimed power in a fair-share order [9, 36] or allocate power proportionally based on estimated demand [35]. These heuristics do not explicitly model application-specific marginal performance gains per additional watt across both CPU and GPU, which can lead to suboptimal allocations for heterogeneous workloads. To address this limitation, we present EcoShift, a performanceaware cluster-wide power distribution framework for heterogeneous CPU–GPU workloads. EcoShift takes a reclaimed-power budget as input and allocates it to the applications that can convert that budget into the largest relative performance gains under the current CPU and GPU cap levels. Throughout the paper, we use runtime as the performance measure (lower is better), and EcoShift’s optimization target is the average relative runtime reduction over

Conference’17, July 2017, Washington, DC, USA

Zhong Zheng, Michael E. Papka, and Zhiling Lan

Figure 1: Heatmaps of normalized application performance on a node with an Intel Xeon Platinum 8468 CPU and NVIDIA H100 GPU under varying CPU and GPU power caps. Four representative cases illustrate distinct sensitivity profiles across applications. • We analyze the impact of CPU and GPU power capping on heterogeneous applications and characterize the resulting performance and power behavior (§2). • We develop EcoShift, a cluster-wide power distribution framework that allocates reclaimed power budgets to maximize average performance improvement. EcoShift employs a dynamicprogramming-based search algorithm to rapidly identify near-optimal power budget distributions (§3–§4). • We extensively evaluate EcoShift on heterogeneous systems using a broad set of benchmarks and applications (§5–§6).

receiver applications under a fixed reclaimed-power budget. The central question we study is: In a power-constrained heterogeneous computing environment that executes diverse applications, how can we distribute reclaimed power across CPU–GPU workloads to maximize average performance improvement under a fixed reclaimed-power budget? Answering this question requires overcoming two challenges. First, the system must characterize each application’s performance surface across CPU–GPU cap pairs online, since production HPC platforms execute a continual stream of diverse workloads whose power–performance behavior is not known in advance. Second, the system must compute a high-quality cluster-wide allocation quickly enough for online use. EcoShift addresses these challenges by combining two components: an online performance predictor [39] that estimates application performance over a wide range of CPU–GPU cap pairs, and a lightweight dynamic-programming-based allocator that selects a near-optimal distribution of reclaimed power. The dynamic program itself is a standard solver for the discretized multiple-choice knapsack formulation; EcoShift’s contribution is to make this formulation practical for cluster-wide heterogeneous power management by coupling it with online-learned CPU–GPU performance surfaces. We implement EcoShift as an open-source system [link1 ] and evaluate it through emulation-based policy studies using a diverse set of heterogeneous CPU–GPU workloads on two platforms equipped with Intel CPUs and NVIDIA A100 and H100 GPUs (§5). The results show that EcoShift predicts performance under diverse CPU–GPU cap settings with mean accuracy of 93–95% and consistently outperforms state-of-the-art cluster-wide power management policies by up to 6% in average performance improvement. Overall, this work offers the following key contributions:

1 GitHub link will be provided upon acceptance

2

Motivation and Challenges

Heterogeneous CPU–GPU applications exhibit diverse and often asymmetric sensitivity to CPU and GPU power caps. As a result, cluster-wide policies that distribute reclaimed power using fairshare heuristics [9, 36] or proportional-to-demand rules [35] can be suboptimal in heterogeneous settings. To quantify this heterogeneity, we conduct extensive power– performance characterization on a system equipped with Intel Xeon CPUs and NVIDIA H100 GPUs. For each application, we sweep CPU and GPU power caps over a wide range and record runtime. Our key finding is that power capping one component (CPU or GPU) can be either performance-neutral or performance-critical, depending on the workload. Figure 1 illustrates four representative applications with distinct sensitivity profiles (Table 1). softmax is highly sensitive to CPU power capping due to communication and memory bottlenecks, but largely insensitive to GPU caps. tealeaf is primarily GPU-bound, making it sensitive to GPU capping but relatively insensitive to CPU caps. ResNet50 exhibits sensitivity to both CPU and GPU caps, reflecting mixed CPU-side orchestration and GPU computation. In contrast, minisweep is largely insensitive to either cap within the evaluated range. Prior work [39] groups heterogeneous applications into coarse sensitivity classes (CPU-sensitive, GPU-sensitive, bothsensitive, and insensitive). However, such coarse labels alone are insufficient for power distribution: for example, although tealeaf is GPU-sensitive, increasing the GPU cap from 450 W to 500 W yields only marginal improvement.

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems

Figure 2: Incremental performance gain from extra GPU & CPU power budget on a node with Intel(R) Xeon(R) Platinum 8468 processors with NVIDIA H100-80GB GPU on two applications from Altis benchmarks. The initial CPU/GPU power caps are set to 300 W and 200 W, respectively. In (a), we fix the GPU power cap and vary the CPU power cap, whereas in (b) we fix the CPU power cap and vary the GPU power cap. Increasing same amount of power budget leads to different performance gains across different applications, processors and the current power cap level.

To further investigate the diminishing returns and cross-component effects, we conduct a sensitivity study (Figure 2) using a CPUsensitive application, cfd, and a GPU-sensitive application, raytracing, on an Intel Xeon Platinum 8468 + NVIDIA H100 node. Starting from CPU/GPU caps of 300 W/200 W, cfd improves by 17% when the CPU cap increases from 300 W to 400 W, but only by 7.6% when increasing from 400 W to 500 W, demonstrating diminishing marginal returns. Similarly, raytracing improves by 15.5% when the GPU cap increases from 200 W to 300 W, but only by 2.1% when increasing from 300 W to 400 W. Finally, additional GPU power provides little benefit to cfd, while additional CPU power provides limited benefit to raytracing, highlighting the importance of cross-component sensitivity. Overall, the benefit of reclaimed power depends jointly on three factors: the application’s CPU–GPU sensitivity, the current cap pair, and the amount of extra power available. Therefore, a clusterwide policy should not ask only who has spare power or who wants more power; it should ask which application can deliver the largest marginal performance gain for the next watt at the current operating point. Existing cluster-wide methods do not explicitly answer this question. Prior approaches typically redistribute reclaimed power using fair-share rules [9, 36] or proportional-to-demand heuristics [35]. Such policies can miss the best allocation because they do not model application-specific marginal gains across both CPU and GPU dimensions. These observations motivate EcoShift. A practical performanceaware policy must solve two problems at once: it must estimate application response to CPU–GPU power changes, and it must search a large combinatorial allocation space quickly enough for online deployment. Specifically, EcoShift must address two key challenges: (1) Online characterization of heterogeneous CPU–GPU applications. Diverse and previously unseen applications can exhibit complex cross-component interactions under different

Conference’17, July 2017, Washington, DC, USA

Figure 3: Workflow of EcoShift. EcoShift begins with a brief online profiling phase, during which all applications are monitored concurrently. Based on the collected runtime signals, it predicts application performance under different powercap configurations. Finally, EcoShift employs a dynamicprogramming-based search to determine the optimal clusterwide power distribution. power caps. Exhaustive offline profiling is costly and impractical in production, so EcoShift must perform fast and accurate online characterization. (2) Scalability of cluster-wide optimization. Finding the optimal power distribution across applications to maximize average performance improvement is NP-hard. The combinatorial search space grows rapidly with the number of applications and available power-cap configurations, making brute-force exploration infeasible in practice.

3

EcoShift Design

The results above show that effective cluster-wide power distribution relies on accurate characterization of application performance under diverse power caps; however, deriving the performance– power relationship for each application remains challenging, particularly for previously unseen workloads without prior extensive offline profiling (the heterogeneity challenge). In addition, the increasing scale of applications makes it difficult to find optimized power caps that maximize performance improvement across all applications (the scalability challenge). Figure 3 shows the EcoShift workflow. EcoShift first performs 1 lightweight online profiling for unseen applications. It then uses the 2 predictor from Zheng et al. [39], which employs neural collaborative filtering to infer performance over a wide range of CPU and GPU cap pairs from a small number of online samples. This step provides the per-application performance surface needed by the allocator without exhaustive profiling. Finally, EcoShift invokes 3 a dynamic-programming-based search to compute the reclaimedpower allocation across applications. We evaluate the predictor in §6; its mean accuracy is approximately 95% on one system and 93% on the other.

3.1

Performance Prediction

EcoShift relies on an online performance predictor [39] to estimate each application’s performance (runtime) under different CPU– GPU power cap pairs. The performance predictor treats performance prediction as a matrix-completion problem, where rows correspond to applications and columns correspond to CPU–GPU power-cap configurations; only a small subset of entries can be measured online due to profiling cost. To infer the unmeasured entries, it uses a neural collaborative filtering (NCF) model that learns latent embeddings for applications and power-cap configurations and predicts performance from their interaction.

Conference’17, July 2017, Washington, DC, USA

Zhong Zheng, Michael E. Papka, and Zhiling Lan

otherwise. Formally, the optimization is: max 𝑥

s.t.

𝑁 1 ∑︁ ∑︁ 𝐼𝑖 (𝑐, 𝑔) 𝑥𝑖,(𝑐,𝑔) 𝑁 𝑖=1 (𝑐,𝑔) ∈ S𝑖 ∑︁ 𝑥𝑖,(𝑐,𝑔) = 1, ∀𝑖, (𝑐,𝑔) ∈ S𝑖 𝑁 ∑︁ ∑︁

 (𝑐 − 𝑐¯𝑖 ) + (𝑔 − 𝑔¯𝑖 ) 𝑥𝑖,(𝑐,𝑔) ≤ 𝐵,

𝑖=1 (𝑐,𝑔) ∈ S𝑖

𝑥𝑖,(𝑐,𝑔) ∈ {0, 1}, Figure 4: Dynamic Programming Search Space. Given a fixed node power budget, EcoShift determines the optimal extra CPU and GPU power distribution for an application, producing an optimal performance curve that serves as the input to the DP algorithm. At runtime, EcoShift performs lightweight online profiling by sampling a few representative CPU–GPU cap pairs for an unseen application and measuring its performance for a short period. These samples are then used to (i) identify the new application’s embedding (and optionally fine-tune the model) and (ii) predict the full performance surface over the feasible cap grid. This design avoids exhaustive offline profiling while still capturing the heterogeneous and cross-component (CPU–GPU) performance response to power capping, enabling EcoShift to quickly evaluate candidate power reallocations during optimization.

3.2

Optimal Power Distribution Search

We consider a cluster running 𝑀 heterogeneous CPU–GPU applications under a fixed cluster-wide power budget 𝑊 . The budget is initially distributed evenly across applications. Some applications draw less than their assigned caps and therefore create a reclaimedpower pool of size 𝐵; others can benefit from additional power. Let A denote the set of running applications with |A| = 𝑀, and partition it into donors D and receivers R, where D ∩ R = ∅ and D ∪ R = A. Let 𝑁 ≜ |R| denote the number of receivers. EcoShift optimizes power allocation only over the applications in R, subject to the reclaimed-power budget 𝐵 supplied by donors. Our focus is the distribution problem: given a reclaimed-power budget, how should it be allocated to maximize average relative performance improvement over receiver applications? The mechanisms used to identify donors and determine 𝐵 are orthogonal to this design. 3.2.1 Multiple-Choice Knapsack Problem Formulation. Suppose receiver application 𝑖 starts from an initial CPU–GPU cap pair (¯ 𝑐𝑖 , 𝑔¯𝑖 ). Using the predicted performance surface, EcoShift enumerates a finite set S𝑖 of feasible upgraded cap pairs for application 𝑖, where each candidate (𝑐, 𝑔) ∈ S𝑖 satisfies 𝑐 ≥ 𝑐¯𝑖 and 𝑔 ≥ 𝑔¯𝑖 . We use runtime as the performance measure, so lower is better. Let 𝑇𝑖 (𝑐, 𝑔) denote the runtime of application 𝑖 under caps (𝑐, 𝑔). The improvement obtained by selecting (𝑐, 𝑔) relative to the baseline 𝑇 (𝑐¯ ,𝑔¯ ) −𝑇 (𝑐,𝑔) (¯ 𝑐𝑖 , 𝑔¯𝑖 ) is the relative runtime reduction 𝐼𝑖 (𝑐, 𝑔) ≜ 𝑖 𝑖𝑇𝑖 (𝑖𝑐¯𝑖 ,𝑔¯𝑖𝑖) . The problem can be transformed into the following multiplechoice knapsack problem. Let 𝑥𝑖,(𝑐,𝑔) be a binary decision variable that equals 1 if application 𝑖 is assigned cap pair (𝑐, 𝑔) ∈ S𝑖 and 0

∀𝑖, (𝑐, 𝑔) ∈ S𝑖 .

This formulation corresponds to a multiple-choice knapsack problem and is NP-hard. Since the search space grows exponentially with the number of applications and possible power cap choices, exhaustive brute-force search is infeasible for online deployment, motivating efficient approximation algorithms. 3.2.2 Dynamic Programming Based Search. We solve the allocation problem with a dynamic-programming-based search. The DP is the standard solver for the multiple-choice knapsack formulation in §3.2.1: each application forms one choice group, and each candidate CPU–GPU cap pair consumes reclaimed power and yields a predicted improvement. To make the search efficient, EcoShift first compresses each application’s discrete option set S𝑖 into a 1D valueversus-budget curve 𝐹𝑖 (𝑏), which records the best improvement achievable when allocating exactly 𝑏 watts of reclaimed power to application 𝑖. For each application 𝑖, EcoShift computes an application-level improvement function 𝐹𝑖 (𝑏), which represents the maximum achievable performance improvement when allocating 𝑏 watts of reclaimed power: 𝐹𝑖 (𝑏) =

max

(𝑐,𝑔) ∈ S𝑖 : (𝑐 −𝑐¯𝑖 )+(𝑔−𝑔¯𝑖 ) ≤𝑏

𝐼𝑖 (𝑐, 𝑔)

(1)

At the cluster level, EcoShift allocates reclaimed power across applications using a DP recurrence:  𝐷𝑃 [𝑖] [𝑏] = max 𝐷𝑃 [𝑖 − 1] [𝑏 − 𝑘] + 𝐹𝑖 (𝑘) , (2) 0≤𝑘 ≤𝑏

where 𝐷𝑃 [𝑖] [𝑏] denotes the maximum aggregate relative performance improvement achievable using the first 𝑖 receiver applications and 𝑏 watts of reclaimed power. An overview of the algorithm is presented in Algorithm 1. Figure 4 illustrates this process for cfd and raytracing. For each application, EcoShift enumerates feasible CPU–GPU cap pairs under the available extra-power budget and discards infeasible or dominated configurations. It then keeps, for each extra-power level, only the cap pair that yields the highest improvement. The resulting monotone curve becomes the input to the cluster-level DP. This preprocessing step greatly reduces the search space while preserving the best allocation choice at each budget level. 3.2.3 Complexity Analysis. Next, we quantify the time complexity of the DP-based search. Let 𝑁𝑟 be the number of receiver applications and 𝐵 the reclaimed power budget, discretized at 1 W granularity. Let 𝑆 denote the average number of feasible CPU–GPU power configurations per receiver application. Constructing the per-application improvement function 𝐹𝑖 (𝑏) requires O (𝑆 · 𝐵) time. Across all receiver applications, this step incurs O (𝑁𝑟 · 𝑆 · 𝐵) time.

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems

Algorithm 1 EcoShift’s DP-based Search: Maximize Average Relative Performance Improvement Require: Receiver applications R, per-application baseline caps {(¯ 𝑐 𝑎 , 𝑔¯𝑎 )}𝑎∈ R , budget 𝐵, power grid G, improvement estimator Δ(·) Ensure: Power allocation per app (may be 0 extra power) 1: options ← [] 2: for each app 𝑎 ∈ R do 3: best[0] ← (0, (¯ 𝑐 𝑎 , 𝑔¯𝑎 )) 4: for each (𝑃𝑐𝑝𝑢 , 𝑃𝑔𝑝𝑢 ) ∈ G do 5: if 𝑃𝑐𝑝𝑢 < 𝑐¯𝑎 or 𝑃𝑔𝑝𝑢 < 𝑔¯𝑎 then 6: continue 7: end if 8: 𝑒 ← (𝑃𝑐𝑝𝑢 − 𝑐¯𝑎 ) + (𝑃𝑔𝑝𝑢 − 𝑔¯𝑎 ) 9: if 𝑒 > 𝐵 then 10: continue 11: end if  12: 𝛿 ← Δ 𝑎, (¯ 𝑐 𝑎 , 𝑔¯𝑎 ), (𝑃𝑐𝑝𝑢 , 𝑃𝑔𝑝𝑢 ) 13: if 𝑒 ∉ best or 𝛿 > best[𝑒].impr then 14: best[𝑒] ← (𝛿, (𝑃𝑐𝑝𝑢 , 𝑃𝑔𝑝𝑢 )) 15: end if 16: end for 17: options.𝑎𝑝𝑝𝑒𝑛𝑑 (best) 18: end for 19: 𝐷𝑃 ← {0 ↦→ (0, ∅)} 20: for each app 𝑎 with option table best do 21: 𝐷𝑃 ′ ← ∅ 22: for each used power 𝑢 in 𝐷𝑃 do 23: for each extra power 𝑒 in best do 24: if 𝑢 + 𝑒 > 𝐵 then 25: continue 26: end if 27: 𝑠 ← 𝐷𝑃 [𝑢].impr + best[𝑒].impr 28: if (𝑢 + 𝑒) ∉ 𝐷𝑃 ′ or 𝑠 > 𝐷𝑃 ′ [𝑢 + 𝑒].impr then 29: 𝐷𝑃 ′ [𝑢 + 𝑒] ← (𝑠, 𝐷𝑃 [𝑢].alloc ∪ {𝑎 ↦→ best[𝑒].power}) 30: end if 31: end for 32: end for 33: 𝐷𝑃 ← 𝐷𝑃 ′ 34: end for ★ ★ 35: (𝑢 ★, alloc ) ← arg max𝑢 𝐷𝑃 [𝑢].impr return alloc

At the cluster level, the DP recurrence above maximizes over 𝑘 ∈ [0, 𝑏] for each state (𝑖, 𝑏), yielding a worst-case time complexity of O (𝑁𝑟 · 𝐵 2 ). Equivalently, when expressed as a multiple-choice knapsack over per-application option sets of size 𝐾𝑖 , the runtime Í is O 𝐵 · 𝑖 𝐾𝑖 ; if 𝐾𝑖 = O (𝐵) in the worst case, this reduces to O (𝑁𝑟 · 𝐵 2 ). In practice, the preprocessing step prunes dominated and infeasible configurations and leaves only a small set of distinct extra-power levels per application, so 𝐾𝑖 ≪ 𝐵 and the practical runtime scales much more gently than the worst case. The space complexity is O (𝑁𝑟 ·𝐵), which can be reduced to O (𝐵) using a rolling-array optimization. In practice, the search overhead

Conference’17, July 2017, Washington, DC, USA

is low enough to support online use; we leave a dedicated overhead breakdown to future work. We also compare the DP-based search with exhaustive bruteforce search in § 6 using small-scale experiments where brute-force enumeration is tractable. The results show that in over 80% of the test cases, EcoShift achieves performance improvements within 3% of the brute-force Oracle solution on both systems.

4

Implementation

We implement EcoShift in Python using native profiling engines that collect runtime signals with minimal disruption, and the code is available as open source on GitHub. Our current prototype targets heterogeneous systems equipped with Intel CPUs and NVIDIA GPUs. For GPU telemetry, EcoShift relies on NVIDIA’s Data Center GPU Manager (DCGM) [25] to sample hardware counters in real time, providing comprehensive visibility without requiring sourcecode changes. For CPU telemetry, EcoShift employs Linux perf to collect hardware performance counters, enabling observation of key processor-level metrics such as memory and instruction throughput. Power measurements are obtained through vendorprovided interfaces, using NVML [26] for GPU power and RAPL (Running Average Power Limit) [21] for CPU power. Although the current implementation uses vendor-specific monitoring APIs, the overall design is portable, and EcoShift can be deployed on other heterogeneous platforms provided that comparable performance counter and power monitoring interfaces are available.

5 Experimental Setting 5.1 Comparison Methods In our experiments, we compare EcoShift against two state-ofthe-art approaches, MixedAdaptive [35] and DPS [9], as well as an Oracle baseline. The Oracle assumes perfect knowledge of the power-cap configuration that maximizes average performance improvement across applications. Because finding this configuration requires exhaustive brute-force search over cross-application cap combinations, it quickly becomes computationally infeasible as the number of applications grows. We therefore compare against the Oracle only in the small-scale study in §6.3.

5.2

Heterogeneous Workloads and Systems

As presented in Table 1, we assemble a diverse suite of 40 heterogeneous CPU–GPU benchmarks and applications: thirteen from Altis [19], thirteen from HecBench [20], three neural-network training workloads from MLPerf [13], four ECP proxy applications [1], two production GPU-enabled molecular-dynamics applications [4, 32], and five SPEC workloads [10]. These workloads span the four sensitivity categories described in §2. For evaluation, we organize them into five workload groups: CPU-sensitive, GPU-sensitive, both-sensitive, insensitive, and mixed. The mixed group includes workloads drawn from all sensitivity categories. Two different heterogeneous systems are used in our evaluation: • System 1: two Intel(R) Xeon(R) Platinum 8380 processors paired with NVIDIA A100-40GB GPUs. • System 2: two Intel(R) Xeon(R) Platinum 8468 processors paired with NVIDIA H100-80GB GPUs.

Conference’17, July 2017, Washington, DC, USA

Zhong Zheng, Michael E. Papka, and Zhiling Lan

Table 1: Heterogeneous Workload. These workloads span four capping sensitivity classes (§2): CPU cap sensitive (C), GPU cap sensitive (G), sensitive to both (B), and insensitive to both (N).

We employ Intel RAPL [8] and NVIDIA NVML [26] for CPU and GPU power capping, respectively. Our approach is not limited to RAPL or NVML and is compatible with any platform that provides equivalent power capping capabilities.

Suite

Input

5.3

EcoShift aims to maximize average performance improvement while also accounting for fairness across applications. Accordingly, we use the following metrics: • Average Performance Improvement. We use runtime as the performance measure (lower is better). We quantify improvement as the percentage runtime reduction relative to the nodistribution baseline, and report 98% confidence intervals. • Fairness. We measure fairness using Jain’s fairness index [2] (Equation 3), where 𝑥𝑖 denotes the performance improvement of application 𝑖 and 𝑛 is the number of applications. The index ranges from 1/𝑛 to 1, with higher values indicating more balanced performance improvements across applications.

App (Class)

Altis

gemm (C) gups (N) maxflops (C) bfs (C) particlefilter_float (G) cfd_double (B) particlefilter_naive (C) raytracing (G) fdtd2d (G) nw (B) cfd (C) lavamd (C) sort (C)

-s 4 -s 4 / -s 4 -s 4 -s 4 -s 4 -s 4 -s 4 -s 4 -s 4 -s 4 -s 3

HeCBench

kalman (C) stencil3d (C) extrema (B) knn (C) dropout (N) aobench (N) zoom (C) convolution3D (B) softmax (C) chacha20 (N) zmddft (G) residualLayerNorm (B) backgroundSubtract (C)

10000 10000 10000 1100 default default default default 64 32 512 512 32 64 128 56 56 3 10000 100000 default default default 1280 2560 2

MLPerf

UNet (B) BERT (G) ResNet50 (B)

carvana image Wiki ImageNet

ECP Proxy

sw4lite (C) XSBench (B) Laghos (N) miniGAN (B)

ps2.in -s large box01_hex.mesh bird, 2048 images, 3 channels, 64×64, dim mode 3

HPC App

GROMACS (C)

Steepest descent, emtol 1000, PBC xyz, PME, rc 1.0 nm 3D LJ melt, 6.25M, 500 steps, cutoff 2.5

LAMMPS (C) SPEC

lbm (G) cloverleaf (C) tealeaf (G) minisweep (N) pot3d (N)

X 1200, Y 4800 X 1500, Y 1500 X 10000, Y 10000 X=Y=Z 128, NE 16 NA 32, NBLOCK_Z 128 NR 67 NT 181 NP 451

Evaluation Metrics

Í𝑛 𝐽 (𝑥 1, . . . , 𝑥𝑛 ) =

5.4

𝑖=1 𝑥𝑖

𝑛

2

2 𝑖=1 𝑥𝑖

Í𝑛

(3)

Emulation-Based Evaluation

Existing approaches often couple power reclamation and redistribution through fixed or utilization-driven policies [9, 35]. EcoShift instead treats reclaimed power as an explicit input and focuses on the distribution problem itself. This separation is important because it lets us evaluate how much benefit can be extracted from a given reclaimed-power budget when application-specific sensitivity and diminishing returns are taken into account. Because our available hardware cannot realize large clusterscale experiments directly, we use an emulation-based methodology. EcoShift first predicts each application’s performance under different CPU and GPU cap pairs. The DP-based optimizer then determines the cap assignment for a given reclaimed-power budget. Each application is next executed individually under its assigned caps, and the measured runtime reduction is used to compute the resulting average performance improvement. This methodology preserves EcoShift’s decision logic while allowing controlled evaluation across many workloads, initial cap settings, and reclaimedpower budgets.

6

Results

Each experiment was repeated five times to account for performance variability and system noise; we report the mean across runs. Our primary objective is to maximize average performance improvement when redistributing a fixed amount of reclaimed power. The following subsections present the emulation-based policy evaluation of EcoShift (Figures 5–8 and Figure 9), a detailed case study (Table 2), the effectiveness of the DP-based search relative to an Oracle (Figure 10), and a fairness analysis (Figure 11).

6.1

Emulation-Based Policy Evaluation

We first compare EcoShift with DPS and MixedAdaptive in terms of average performance improvement. As discussed in §2, the gain

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems

Figure 5: Performance improvement of different power distribution methods across diverse workloads on simulated 100-node System 1 clusters under varying amounts of cluster wide extra power, measured relative to a no distribution baseline The initial power cap is CPU 140 W, and GPU 150 W from redistribution depends on three factors: application sensitivity to CPU and GPU caps, the initial cap pair, and the reclaimed-power budget 𝐵. The experiments below vary these factors in a controlled way. Figure 5 fixes the initial cap pair at 140 W CPU and 150 W GPU and varies 𝐵. Each row corresponds to one workload category from §5. The x-axis shows the reclaimed power redistributed across applications, and the y-axis shows the resulting average performance improvement relative to the no-distribution baseline. Figure 6 instead fixes 𝐵 at 3500 W and sweeps the initial CPU/GPU cap pairs. This emulation-based experiment tests whether the policy remains effective when the system starts in a tight-cap regime versus a relatively power-sufficient regime. EcoShift’s advantage is largest when the initial caps are tight, where there is more room for performanceaware reallocation; as the initial caps increase, all methods converge because the workloads become less power-constrained. Three trends are clear from the System 1 results. First, across workload categories, reclaimed-power budgets, and initial cap settings, EcoShift consistently matches or exceeds DPS and MixedAdaptive, with improvements of up to 6%. Second, EcoShift also tends to achieve higher upper bounds in the 98% confidence intervals, indicating that it can better exploit favorable sensitivity when such opportunities exist. Third, gains remain small for insensitive workloads under all methods, which is expected because these applications respond weakly to additional power. The same qualitative behavior appears on System 2 in Figures 7 and 8. Thus, the

Conference’17, July 2017, Washington, DC, USA

Figure 6: Performance improvement of different power distribution methods across diverse workloads on simulated 100-node System 1 clusters under varying initial CPU and GPU power cap with fixed cluster-wide extra power budget (7000 W), measured relative to a no distribution baseline. ranking of methods is stable across both platforms and workload groups: EcoShift is consistently comparable to or better than DPS and MixedAdaptive because it allocates reclaimed power jointly across CPU and GPU instead of relying on fixed-share or demandbased heuristics. Beyond average performance improvement, it is also important to examine the distribution of performance gains across individual applications. Figure 9 presents violin plots showing the distributions of application level performance improvement across different workload categories under various power distribution methods. Across most workload types, EcoShift exhibits distributions that are shifted toward higher performance improvements, indicating that EcoShift not only increases average performance but also enables a larger fraction of applications to achieve higher performance gains. Because EcoShift’s allocations rely on predicted performance surfaces, we next verify the prediction accuracy of the performance predictor introduced in [39]. For each CPU–GPU power cap configuration, prediction accuracy is defined as Acc = 1 − |𝑝ˆ − 𝑝 |/𝑝, where 𝑝 and 𝑝ˆ represent the measured and predicted normalized performance relative to the baseline. We report the mean accuracy across applications and CPU–GPU cap points. On system 2, the predictor achieves a mean accuracy of 93.12%, with a 98% confidence interval of [92.64%, 94.01%]. Similar accuracy is observed on system 1, where the mean accuracy reaches 95.12%, with a 98%

Conference’17, July 2017, Washington, DC, USA

Zhong Zheng, Michael E. Papka, and Zhiling Lan

Figure 7: Performance improvement of different power distribution methods across diverse workloads on simulated 100-node System 2 clusters under varying amounts of cluster wide extra power, measured relative to a no distribution baseline. The initial power cap is CPU 300 W, and GPU 300 W Table 2: Performance improvement under a baseline cap of (300 W CPU, 200 W GPU) for two H100 applications, with 200 W of reclaimed power available for redistribution. The table reports the post-allocation CPU/GPU caps selected by each policy under the monotonic upgrade model used in EcoShift. Policy

App

EcoShift

raytracing cfd

CPU, GPU Power (W)

Perf. Gain (%)

(300, 300) (400, 200)

15.57 18.35

Average DPS

raytracing cfd

(350, 250) (350, 250) Average

MixedAdaptive

raytracing cfd

(329, 294) (354, 221) Average

16.96 9.61 8.81 9.21 17.03 9.29 13.16

confidence interval of [94.64%, 96.01%]. Given this 93–95% mean accuracy, residual error primarily affects close-call allocations in which multiple candidate power-cap choices yield marginal performance gains that differ only slightly; we quantify this effect by comparing EcoShift with an Oracle in § 6.3.

Figure 8: Performance improvement of different power distribution methods across diverse workloads on simulated 100-node System 2 clusters under varying initial CPU and GPU power cap with fixed cluster-wide extra power budget (14000 W), measured relative to a no distribution baseline.

6.2

A Case Study for Detailed Analysis

We next examine a simple two-application case to show why EcoShift improves average performance. We revisit the example in Figure 2. Under the baseline caps of 300 W CPU and 200 W GPU, cfd benefits strongly from additional CPU power, whereas raytracing benefits primarily from additional GPU power. Table 2 shows the resulting allocations under the monotonic upgrade model used throughout the paper, where reclaimed power can only raise an application’s CPU and GPU caps relative to baseline. EcoShift assigns the full 100 W CPU increase to cfd, moving it from (300, 200) to (400, 200), and assigns the remaining 100 W to raytracing, moving it to (300, 300). By contrast, DPS applies the same split to both applications, and MixedAdaptive allocates power according to inferred demand rather than predicted marginal gain. The comparison makes the mechanism behind EcoShift clear: it spends power where the next watt is predicted to help most. Under this policy, EcoShift achieves 16.96% average improvement, well above DPS (9.21%) and MixedAdaptive (13.16%). This case study shows that EcoShift improves average performance not by enforcing a uniform rule, but by matching each power increment to the application’s dominant sensitivity within the feasible upgrade set.

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems

Conference’17, July 2017, Washington, DC, USA

Figure 9: Violin plots showing the distributions of performance improvement across different type of workloads under different power distribution methods. The experiment is emulated on a 100-node system 1 cluster with an initial CPU and GPU power cap of 140 W and 150 W respectively.

6.3

Gap to Oracle

The gap to the Oracle captures the overall suboptimality of EcoShift. This gap comes from two sources: prediction error, because EcoShift optimizes over predicted rather than measured performance surfaces, and optimization error, because the search operates on a discretized formulation. Comparing EcoShift against an exhaustive brute-force Oracle therefore evaluates the full pipeline of prediction plus allocation. To do this evaluation, we randomly select ten applications from the mixed workload set and repeat this selection process five times. For each selection, we evaluate five different initial power cap configurations, ranging from small to large, and four different reclaimed power budget levels, resulting in a total of 100 test configurations. Each test configuration consists of ten applications with distinct power settings. We limit the evaluation to ten applications per configuration to keep the brute-force search tractable, as larger configurations become prohibitively time-consuming. Figure 10 plots the cumulative distribution of the performanceimprovement gap (in percentage points) between EcoShift’s DPbased solution and the Oracle. For example, if the DP-based solution achieves a 10% performance improvement while the Oracle achieves 15%, the absolute gap is 5 percentage points. We can observe that, in most cases, the gap between EcoShift and the Oracle remains within a small margin. On H100, EcoShift achieves a median (mean) gap of 1.45 (1.48) percentage points, with a 90th-percentile gap of 2.24 percentage points; 27.5% and 77.5% of test cases are within 1 and 2 percentage points of the Oracle, respectively. On A100, EcoShift achieves a median (mean) gap of 1.20 (1.33) percentage points, with a 90th-percentile gap of 2.76 percentage points; 42.5% and 80.0% of test cases are within 1 and 2 percentage points of the Oracle, respectively. Overall, on both systems, 90% of the test cases exhibit less than a 3 percentage-point gap, demonstrating that the DP-based search closely approximates the optimal solution. This shows that the DP-based search remains close to the Oracle while preserving the low-overhead structure needed for online use.

6.4

Fairness Analysis

Average performance is the primary objective, but fairness also matters for a cluster-wide policy. We use Jain’s fairness index to quantify how evenly performance improvements are distributed across applications. In Equation 3, 𝑥𝑖 denotes the performance improvement of application 𝑖 and 𝑛 is the number of applications. The

Figure 10: Cumulative distribution function of the performance improvement gap between EcoShift’s DP-based search and the Oracle across all 100 test cases. The performance improvement gap is defined as the difference in average performance improvement (%) between the Oracle, which assumes perfect knowledge of application performance at every power level and identifies the optimal allocation via exhaustive brute-force search, and EcoShift’s DP-based search. index ranges from 1/𝑛 to 1, where larger values indicate a more even distribution of gains. Jain’s index is appropriate here because it captures relative balance across applications while remaining invariant to scale. For each experiment configuration, we compute Jain’s fairness index over the per-application improvements produced by each policy. Figure 11 summarizes these values for the mixed-workload experiments on both systems. EcoShift exhibits larger variance, which is expected: a policy that targets marginal gains will sometimes concentrate power on a smaller set of highly responsive applications. Even so, EcoShift achieves median fairness comparable to DPS and MixedAdaptive. Thus, EcoShift improves average performance without introducing a systematic fairness collapse.

7

Discussion

Key strength. A key strength of EcoShift is its ability to make performance-aware cluster-wide power distribution decisions for heterogeneous CPU–GPU workloads without expensive offline profiling. By combining lightweight online profiling, an online performance predictor, and a DP-based optimizer, EcoShift can (i) quickly characterize each application’s CPU–GPU power sensitivity and diminishing returns, and (ii) compute a near-optimal

Conference’17, July 2017, Washington, DC, USA

Zhong Zheng, Michael E. Papka, and Zhiling Lan

memory bandwidth a potentially valuable signal for guiding power distribution decisions.

8

Figure 11: Jain’s fairness index of the mixed workloads. reclaimed-power allocation with low enough overhead for practical deployment. Average-improvement gain. Although EcoShift’s improvement over state-of-the-art policies is up to 6% on average, this metric is computed over the full evaluated workload mix rather than a single best-case application. In an HPC setting, even a few-percent increase in average performance improvement can translate into meaningful throughput benefit across the workload mix. EcoShift’s gains are not driven by a single outlier. The applicationlevel distributions in Figure 9 show that a larger fraction of applications achieve higher improvements under EcoShift than under DPS and MixedAdaptive. While EcoShift may allocate more power to the most power-sensitive applications (potentially reducing improvement for a small subset of less sensitive applications), Figure 11 shows that EcoShift still achieves median fairness comparable to the baselines, indicating that these gains do not come at the cost of severe imbalance. Online profiling. In this work, EcoShift performs online profiling only once for unseen applications to initialize the performance predictor, and then reuses the inferred performance surface for subsequent optimization decisions. This design matches the reality of many HPC applications and deep learning workloads, which often exhibit repetitive phase behavior [41] (i.e., recurring power–performance patterns over time). As a result, a short (e.g., one-minute) profiling phase can be sufficient for the predictor to capture the key performance–power behavior and generalize to later phases of the same execution. Emulation-based evaluation. Our emulation-based cluster evaluation enables scalable exploration across many workloads, but it does not capture all effects that may arise in real deployments (e.g., thermal throttling and transient power-cap enforcement dynamics). Strengthening validation with real concurrent executions, reporting end-to-end control overhead (profiling time, prediction latency, and re-optimization frequency), and exploring interactions with scheduler and partitioning mechanisms (e.g., GPU partitioning) would further improve operational relevance. Evaluation system diversity. Our current evaluation focuses on systems equipped with Intel CPUs and NVIDIA GPUs. However, EcoShift’s design is not tied to a specific hardware vendor and can be extended to other heterogeneous architectures that expose similar power-capping mechanisms. This includes emerging APU platforms such as AMD MI300A [3], which colocate CPU and GPU cores within a single package and operate under a shared socketlevel power budget. In these tightly integrated environments, the strong coupling between CPU and GPU resources makes shared

Related Work

Power and energy have become first-order constraints in largescale HPC systems [5]. To operate within a global power envelope, prior work has explored cluster-wide budgeting, node-level caps, and DVFS-based control [7, 11, 12, 16, 17, 24, 28, 30, 33, 38, 40]. A common baseline is to distribute the available budget uniformly across nodes or applications and then enforce local power caps. A central limitation of uniform budgeting is that applications respond very differently to power capping. Prior studies show that some workloads cannot fully use their assigned budgets, whereas others experience substantial slowdown under the same cap [29]. This observation has motivated a large body of work on redistributing reclaimed power. Existing work can be grouped into three categories: node-level CPU–GPU coordination, application-level redistribution, and cluster-level redistribution. At the node level, prior work studies how to divide a fixed power budget between CPU and GPU within a single heterogeneous application [14, 27, 34]. These methods are valuable for intra-node coordination, but they do not address how reclaimed power should be distributed across multiple applications at the cluster level. At the application level, prior work focuses on imbalance within a parallel job or among dependent applications. PShifter redistributes power across MPI ranks according to observed load imbalance [15], while PoDD allocates power across dependent applications to improve the pace of the bottleneck stage [37]. These works optimize performance within an application or a tightly coupled application set rather than across an entire heterogeneous workload mix. At the cluster level, DPS redistributes reclaimed power according to a fixed-share policy [9], and MixedAdaptive allocates excess power based on demand inferred from current power draw [35]. These approaches are closest to our setting, but they do not explicitly optimize application-specific marginal gains across both CPU and GPU dimensions. EcoShift differs by using predicted CPU– GPU performance surfaces to allocate reclaimed power where it produces the largest expected marginal gain. To the best of our knowledge, EcoShift is the first cluster-level, performance-aware power distribution framework that jointly considers CPU and GPU while targeting average performance improvement under a fixed reclaimed-power budget.

9

Conclusion

As heterogeneous CPU–GPU workloads become more common, cluster-wide power management must account for applicationspecific sensitivity to CPU and GPU power caps. We presented EcoShift, an online framework that combines lightweight profiling, performance prediction, and dynamic-programming-based optimization to redistribute reclaimed power across applications. Across two heterogeneous platforms and diverse CPU–GPU workloads, EcoShift consistently improves average performance over state-ofthe-art policies by up to 6% while maintaining comparable mean fairness. These results show that performance-aware redistribution can turn reclaimed power into system-level benefit. As future work, we plan to integrate EcoShift with production schedulers

EcoShift: Performance-Aware Power Management for Power-Constrained Heterogeneous Systems

such as Slurm, enabling periodic cap updates and re-optimization as applications arrive and depart.

Conference’17, July 2017, Washington, DC, USA

References [1] 2025. ECP proxy apps suite. https://proxyapps.exascaleproject.org/ ecp- proxyapps- suite/. [2] 2025. Jain’s fairness index. "https://en.wikipedia.org/wiki/Fairness_measure". [3] AMD. 2025. AMD MI300A. "https://www.amd.com/en/products/accelerators/ instinct/mi300/mi300a.html". [4] Large-scale Atomic and Molecular Massively Parallel Simulator. 2013. Lammps. available at: http:/lammps. sandia. gov (2013). [5] Keren Bergman, Shekhar Borkar, Dan Campbell, William Carlson, William Dally, Monty Denneau, Paul Franzon, William Harrod, Kerry Hill, Jon Hiller, et al. 2008. Exascale computing study: Technology challenges in achieving exascale systems. Defense Advanced Research Projects Agency Information Processing Techniques Office (DARPA IPTO), Tech. Rep 15 (2008), 181. [6] Melanie Cornelius, Greg Cross, Shilpika Shilpika, Matthew T Dearing, and Zhiling Lan. 2025. Extracting Practical, Actionable Energy Insights from Supercomputer Telemetry and Logs. arXiv preprint arXiv:2505.14796 (2025). [7] Howard David, Chris Fallin, Eugene Gorbatov, Ulf R Hanebutte, and Onur Mutlu. 2011. Memory power management via dynamic voltage/frequency scaling. In Proceedings of the 8th ACM international conference on Autonomic computing. 31–40. [8] Howard David, Eugene Gorbatov, Ulf R Hanebutte, Rahul Khanna, and Christian Le. 2010. RAPL: Memory power estimation and capping. In Proceedings of the 16th ACM/IEEE international symposium on Low power electronics and design. 189–194. [9] Jianru Ding and Henry Hoffmann. 2023. DPS: Adaptive Power Management for Overprovisioned Systems. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. 1–14. [10] Kaivalya M Dixit. 1991. The SPEC benchmarks. Parallel computing 17, 10-11 (1991), 1195–1209. [11] Bishwajit Dutta, Vignesh Adhinarayanan, and Wu-chun Feng. 2018. GPU power prediction via ensemble machine learning for DVFS space exploration. In Proceedings of the 15th ACM International Conference on Computing Frontiers. 240–243. [12] Kaijie Fan, Biagio Cosenza, and Ben Juurlink. 2019. Predictable GPUs Frequency Scaling for Energy and Performance. In Proceedings of the 48th International Conference on Parallel Processing. ACM, 1–10. [13] Steven Farrell, Murali Emani, Jacob Balma, Lukas Drescher, Aleksandr Drozd, Andreas Fink, Geoffrey Fox, David Kanter, Thorsten Kurth, Peter Mattson, et al. 2021. MLPerf™ HPC: A holistic benchmark suite for scientific machine learning on HPC systems. In 2021 IEEE/ACM Workshop on Machine Learning in High Performance Computing Environments (MLHPC). IEEE, 33–45. [14] Rong Ge, Xizhou Feng, Yangyang He, and Pengfei Zou. 2016. The case for cross-component power coordination on power bounded systems. In 2016 45th International Conference on Parallel Processing (ICPP). IEEE, 516–525. [15] Neha Gholkar, Frank Mueller, Barry Rountree, and Aniruddha Marathe. 2018. Pshifter: Feedback-based dynamic power shifting within hpc jobs for performance. In Proceedings of the 27th International Symposium on High-Performance Parallel and Distributed Computing. 106–117. [16] Joao Guerreiro, Aleksandar Ilic, Nuno Roma, and Pedro Tomas. 2018. GPGPU power modeling for multi-domain voltage-frequency scaling. In 2018 IEEE International Symposium on High Performance Computer Architecture (HPCA). IEEE, 789–800. [17] João Guerreiro, Aleksandar Ilic, Nuno Roma, and Pedro Tomás. 2019. DVFSaware application classification to improve GPGPUs energy efficiency. Parallel Comput. 83 (2019), 93–117. [18] Sunpyo Hong and Hyesoon Kim. 2010. An integrated GPU power and performance model. In Proceedings of the 37th annual international symposium on Computer architecture. 280–289. [19] Bodun Hu and Christopher J Rossbach. 2020. Altis: Modernizing gpgpu benchmarks. In 2020 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, 1–11. [20] Zheming Jin and Jeffrey S Vetter. 2023. A benchmark suite for improving performance portability of the sycl programming model. In 2023 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, 325–327. [21] Kashif Nizam Khan, Mikael Hirki, Tapio Niemi, Jukka K Nurminen, and Zhonghong Ou. 2018. Rapl in action: Experiences in using rapl for power measurements. ACM Transactions on Modeling and Performance Evaluation of Computing Systems (TOMPECS) 3, 2 (2018), 1–26. [22] Jungseob Lee, Vijay Sathisha, Michael Schulte, Katherine Compton, and Nam Sung Kim. 2011. Improving throughput of power-constrained GPUs using dynamic voltage/frequency and core scaling. In 2011 International Conference on Parallel Architectures and Compilation Techniques. IEEE, 111–120. [23] Charles Lefurgy, Xiaorui Wang, and Malcolm Ware. 2008. Power capping: a prelude to power shifting. Cluster Computing 11 (2008), 183–195. [24] Paul Messina. 2017. The USDOE Exascale Computing Project–Goals and Challenges. "https://www.nist.gov/system/files/documents/2017/02/21/messina_nist_ 20170214.final_.pdf".

Conference’17, July 2017, Washington, DC, USA

[25] NVIDIA. 2025. NVIDIA Data Center GPU Manager. "https://github.com/NVIDIA/ DCGM". [26] Nvidia. 2025. NVML. "https://developer.nvidia.com/management-library-nvml". [27] Cristobal Ortega, Lluc Alvarez, Alper Buyuktosunoglu, Ramon Bertran, Todd Rosedahl, Pradip Bose, and Miquel Moreto. 2022. Adaptive power shifting for power-constrained heterogeneous systems. IEEE Trans. Comput. 72, 3 (2022), 627–640. [28] Tapasya Patki, David K Lowenthal, Barry Rountree, Martin Schulz, and Bronis R De Supinski. 2013. Exploring hardware overprovisioning in power-constrained, high performance computing. In Proceedings of the 27th international ACM conference on International conference on supercomputing. 173–182. [29] Srinivasan Ramesh, Swann Perarnau, Sridutt Bhalachandra, Allen D Malony, and Pete Beckman. 2019. Understanding the impact of dynamic power capping on application progress. In 2019 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE, 793–804. [30] Varun Sakalkar, Vasileios Kontorinis, David Landhuis, Shaohong Li, Darren De Ronde, Thomas Blooming, Anand Ramesh, James Kennedy, Christopher Malone, Jimmy Clidaras, et al. 2020. Data center power oversubscription with a medium voltage power plane and priority-aware capping. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems. 497–511. [31] Tapan Srivastava, Huazhe Zhang, and Henry Hoffmann. 2022. Penelope: peer-topeer power management. In Proceedings of the 51st International Conference on Parallel Processing. 1–11. [32] David Van Der Spoel, Erik Lindahl, Berk Hess, Gerrit Groenhof, Alan E Mark, and Herman JC Berendsen. 2005. GROMACS: fast, flexible, and free. Journal of computational chemistry 26, 16 (2005), 1701–1718. [33] Qiang Wang and Xiaowen Chu. 2020. GPGPU performance estimation with core and memory frequency scaling. IEEE Transactions on Parallel and Distributed Systems 31, 12 (2020), 2865–2881.

Zhong Zheng, Michael E. Papka, and Zhiling Lan

[34] Yiming Wang, Weizhe Zhang, Meng Hao, Weizhi Kong, and Yuan Wen. 2025. Dynamic Power Management Through Multi-agent Deep Reinforcement Learning for Heterogeneous Systems. ACM Transactions on Architecture and Code Optimization (2025). [35] Daniel C Wilson, Siddhartha Jana, Aniruddha Marathe, Stephanie Brink, Christopher M Cantalupo, Diana R Guttman, Brad Geltz, Lowren H Lawson, Asma H Al-Rawi, Ali Mohammad, et al. 2021. Introducing application awareness into a unified power management stack. In 2021 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE, 320–329. [36] Andy B Yoo, Morris A Jette, and Mark Grondona. 2003. Slurm: Simple linux utility for resource management. In Workshop on job scheduling strategies for parallel processing. Springer, 44–60. [37] Huazhe Zhang and Henry Hoffmann. 2019. PoDD: power-capping dependent distributed applications. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. 1–23. [38] Yijia Zhang, Qiang Wang, Zhe Lin, Pengxiang Xu, and Bingqiang Wang. 2024. Improving gpu energy efficiency through an application-transparent frequency scaling policy with performance assurance. In Proceedings of the Nineteenth European Conference on Computer Systems. 769–785. [39] Zhong Zheng, Zhiling Lan, Xingfu Wu, Valerie E Taylor, and Michael E Papka. 2025. Coordinated power management on heterogeneous systems. arXiv preprint arXiv:2508.07605 (2025). [40] Zhong Zheng, Seyfal Sultanov, Michael E Papka, and Zhiling Lan. 2025. Minimizing Power Waste in Heterogenous Computing via Adaptive Uncore Scaling. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. 505–518. [41] Pengfei Zou, Ang Li, Kevin Barker, and Rong Ge. 2020. Indicator-directed dynamic power management for iterative workloads on GPU-accelerated systems. In 2020 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID). IEEE, 559–568.

Record · ID 120474 · SHA-256 a436d460805e21a9
Conceptio Open Knowledge Archive — every document is proof-bundled with source, license, and retrieval metadata.