---
title: 'EcoSched: Eco-Aware Scheduling'
url: https://www.emergentmind.com/topics/ecosched
type: topic
---

# EcoSched: Eco-Aware Scheduling

Searching arXiv for papers explicitly related to EcoSched and closely adjacent eco-aware schedulers.
EcoSched denotes an energy-aware scheduling approach whose concrete meaning is domain-specific in the recent literature. In a shared-facility supercomputing center, it is an energy-aware job–cluster scheduler for a heterogeneous supercomputing center that decides where to run each parallel job so as to minimize energy per useful work while bounding the allowed increase in runtime [2111.08978]. In multi-GPU HPC, it is an online scheduler that jointly optimizes GPU count selection and application coscheduling to improve workload-level efficiency on multi-GPU systems [2604.17640]. This suggests a broader umbrella usage for eco-aware schedulers that explicitly trade energy, energy-delay product, or carbon cost against bounded performance degradation.

## 1. Scope and principal usages

In the literature summarized here, the same label refers to two closely related but technically distinct scheduler families.

| Usage | Domain | Primary decision |
|---|---|---|
| EcoSched | Shared-facility supercomputing center | Select the computing complex for each parallel job |
| EcoSched | Multi-GPU HPC node | Select GPU counts and coscheduled job sets |

The first usage is centered on heterogeneous computing complexes such as KNL, Broadwell, Skylake, and Cascade Lake systems managed through a Job Management System such as SUPPZ [2111.08978]. The second usage is centered on heterogeneous CPU–GPU platforms with 4×H100, 4×A100, and 4×V100 nodes, where the scheduler acts at node level and decides both how many GPUs to allocate to each job and which jobs to run concurrently [2604.17640].

A plausible implication is that EcoSched is best understood not as a single algorithmic artifact, but as a design pattern for eco-aware scheduling under explicit performance constraints. In both principal usages, empirical runtime or energy profiling replaces purely analytic modeling, and the scheduler acts above or beside an existing execution substrate rather than redefining the entire batch system.

## 2. EcoSched in shared-facility supercomputing centers

In the supercomputing-center formulation, EcoSched is a meta-scheduler over heterogeneous computing complexes. Jobs are submitted via a JMS with parameters such as number of processors, requested walltime \(T_{\max}\), and resource type, and the scheduler decides which computing complex should execute the job [2111.08978]. The motivating setting is a shared facility in which older and newer clusters coexist, so that some systems are fast but power-hungry while others are slower but more energy-efficient.

The core efficiency metric is energy per operation,
\[
C = \frac{W}{P},
\]
where \(W\) is the average node power during the run and \(P\) is the number of computational operations executed per second. The paper defines a power consumption profile of a parallel application as a set of pairs \((K,C)\), where \(K\) is the coefficient of acceptable increase in execution time, in percent, and \(C\) is the energy consumption coefficient in J/op [2111.08978].

Given program \(p\) and system \(i\), let \(T_{p,i}\) be runtime and \(C_{p,i}\) be energy per operation. With
\[
T_p^{\min} = \min_i T_{p,i},
\]
the admissible systems satisfy
\[
T_{p,i} \le (1 + K/100)\, T_p^{\min},
\]
and the scheduler chooses
\[
i^* \in \arg\min_i C_{p,i}
\quad \text{s.t.} \quad
T_{p,i} \le (1 + K/100)\, T_p^{\min}.
\]
This is a constrained optimization, not a weighted sum: minimize \(C\) subject to bounded slowdown.

Operationally, the algorithm is a per-job cluster selector that learns from prior executions of the same program on different computing complexes. It constructs a candidate system list, fetches or initializes historical \(C\) and \(T\) values, selects the system with minimal \(C\) satisfying the \(K\) constraint, and stores updated measurements after completion. If no measurements exist, the job is run on the first available computing system, which functions as an exploration step. The implementation computes a hash of the executable as a program identifier and integrates this logic into SUPPZ through a modified `mpirun` interface [2111.08978].

The slowdown bound can be administratively fixed or automatically inferred from the user walltime request. When a prior runtime \(T\) is known and does not exceed \(T_{\max}\), the paper gives
\[
K = \frac{T_{\max} - T}{T}.
\]
This makes \(K\) a slack-derived tolerance: if actual runtime is far below the requested walltime, the scheduler is permitted to choose a slower but more energy-efficient complex.

## 3. EcoSched in multi-GPU HPC

In the 2026 usage, EcoSched is an online scheduler for multi-GPU HPC nodes that jointly optimizes GPU count selection and application coscheduling [2604.17640]. The target environment is a node with several GPUs and a batch of multi-GPU jobs, where the scheduler must decide both how many GPUs to give each job and which jobs to run together so that total workload energy is reduced while makespan and throughput remain favorable.

The motivating observation is that GPU applications exhibit heterogeneous and nonlinear scaling. The paper reports that for some applications, such as miniweather, the performance-optimal GPU count is 1 on H100 but 4 on V100, and that for GPT-2 on H100, using one fewer GPU than the performance-optimal configuration causes only about 3% extra runtime but 24% less energy [2604.17640]. Consequently, neither “always use all GPUs” nor “always use the performance-optimal GPU count in isolation” is adequate.

EcoSched profiles each application briefly at different feasible GPU counts and uses GPU DRAM utilization as a relative performance proxy. For application \(i\) and GPU count \(g\), it derives a normalized runtime estimate \(\hat{T}^{\text{norm}}_{i,g}\), measures average busy power \(\bar{P}_{i,g}\), and defines a normalized energy proxy
\[
\tilde{E}_{i,g} = \bar{P}_{i,g} \cdot \hat{T}^{\text{norm}}_{i,g},
\qquad
\hat{E}^{\text{norm}}_{i,g} =
\frac{\tilde{E}_{i,g}}{\min_{g'} \tilde{E}_{i,g'}}.
\]
Modes with excessive slowdown are filtered using a slowdown tolerance \(\tau\), so the scheduler does not pursue large energy reductions through arbitrarily poor performance.

At each scheduling event, an action \(a\) is a feasible set of job modes, each mode specifying an application and a GPU count. EcoSched evaluates an action through two quantities: energy regret and idle-GPU fraction. With \(|a|\) denoting the number of modes in the action and \(G(a)\) the number of GPUs it consumes,
\[
R_{\text{energy}}(a)
=
\frac{1}{|a|}
\sum_{m\in a}
\left(\hat{E}^{\text{norm}}_{m} - 1\right),
\]
\[
I(a) = \frac{G_{\text{free}} - G(a)}{M},
\]
and the score is
\[
S(a) = R_{\text{energy}}(a) + \lambda I(a).
\]
The scheduler selects
\[
a^* = \arg\min_{a \in \mathcal{A}_{\text{feas}}} S(a).
\]
This formalizes the trade-off between per-job energy efficiency and leaving GPUs idle.

Placement is NUMA-aware. On the dual-socket systems used in the experiments, EcoSched co-allocates at most one application per NUMA domain and binds applications with `numactl`, while controlling GPU visibility through `CUDA_VISIBLE_DEVICES`. Runtime telemetry comes from NVIDIA DCGM and NVML. This design makes the scheduler conservative with respect to LLC and DRAM interference while still permitting nontrivial GPU-count asymmetries, such as one application using 3 GPUs and another 1 GPU on the same 4-GPU node [2604.17640].

## 4. Shared algorithmic themes

Despite their different operating scales, the two EcoSched formulations share a common optimization structure. Each scheduler uses empirical profiling to estimate a feasible subset of configurations and then applies a constrained or score-based selector rather than an unconstrained throughput maximizer.

In the shared-facility formulation, the selector minimizes energy per operation \(C\) subject to a user- or administrator-defined slowdown bound \(K\) [2111.08978]. In the multi-GPU formulation, the selector minimizes a score that combines normalized energy regret with idle-resource penalty, again under an explicit slowdown filter \(\tau\) [2604.17640]. In both cases, the scheduler is not primarily attempting to predict absolute optimal performance across all future jobs; it is making bounded, online decisions over a small feasible action set.

A second shared feature is non-intrusive integration. The supercomputing-center EcoSched leaves per-cluster queueing policies, node placement within a cluster, and DVFS settings unchanged, acting only as a cluster-level router [2111.08978]. The multi-GPU EcoSched similarly assumes a node-level scheduler underneath a global batch scheduler, using profiling and placement controls rather than redefining cluster-wide admission control [2604.17640]. This suggests that EcoSched is structurally closer to a meta-scheduler or node-local policy layer than to a monolithic replacement for existing batch systems.

A third shared feature is controlled exploitation of heterogeneity. In the supercomputing-center case, heterogeneity lies in computing complexes with different performance-per-watt characteristics. In the multi-GPU case, heterogeneity appears in both application scaling curves and platform generations. The scheduler’s eco-efficiency therefore depends less on universal hardware rules than on application-specific empirical response surfaces.

## 5. Evaluation and observed trade-offs

For the shared-facility scheduler, experiments used NAS Parallel Benchmarks 3.3, class D, specifically BT, EP, IS, LU, and SP, across Broadwell, Cascade Lake, KNL, and Skylake systems [2111.08978]. The reported aggregate result is that “for the test suite shown in Table 1, it was possible to reduce power consumption by an average of 21.5%, while the test suite execution time increased by 3.8%.” The paper also notes that for all benchmarks except LU, energy reduction is achieved with an allowable slowdown of less than 5%.

For the multi-GPU scheduler, experiments used 17 applications spanning NVIDIA CUDA samples, SPEC HPC benchmarks such as `lbm`, `cloverleaf`, `tealeaf`, `minisweep`, `pot3d`, and `miniweather`, and ML workloads including `ResNet50`, `ResNet101`, `ResNet152`, `VGG16`, `VGG19`, `BERT`, and `GPT2` on H100, A100, and V100 systems [2604.17640]. Relative to `sequential_optimal_gpu`, EcoSched achieved on H100 up to 14.8% energy savings, 30.1% makespan improvement, and 40.4% EDP reduction. On V100, the paper reports 4.4% energy saving, 14.1% makespan improvement, and 17.9% EDP saving.

These results clarify a recurrent misconception in eco-aware scheduling: energy-efficient scheduling need not imply throughput loss at system level. In the supercomputing-center setting, modest per-job slowdown can lower energy substantially with only small aggregate runtime increase [2111.08978]. In the multi-GPU setting, slight per-application slowdowns can shorten workload makespan because freed GPUs enable beneficial coscheduling [2604.17640]. The underlying mechanism is different in each case, but the principle is the same: local performance maximization is not equivalent to workload-level efficiency.

## 6. Related eco-aware schedulers and broader significance

Related research situates EcoSched within a wider family of eco-aware schedulers. In Industry 4.0 production systems, EasySched is a multi-agent architecture for predictive and reactive scheduling based on available renewable energy, using PSO in the predictive phase and rescheduling via machine-speed adjustments in the reactive phase [1905.12083]. In serverless systems, EcoLife is a carbon-aware scheduler that co-optimizes carbon footprint and performance by exploiting multi-generation hardware and PSO-based keep-alive decisions [2409.02085]. For workflow DAGs with fixed mapping and deadline, CaWoSched addresses carbon-aware scheduling against interval-based green-energy availability [2507.08725]. For TOU-based tariffs on parallel identical machines, exact and heuristic formulations of bi-objective energy-efficient scheduling formalize makespan–energy trade-offs under time-varying electricity prices [2203.14070].

This surrounding literature suggests that EcoSched is part of a larger methodological shift from throughput-only scheduling toward schedulers that expose explicit trade-off parameters and optimize directly against energy or carbon objectives. The HPC-specific EcoSched variants are distinguished by their reliance on empirical profiling, bounded degradation policies, and compatibility with existing scheduling substrates, rather than by any single universal optimization model. In that sense, EcoSched names a family of schedulers that treat eco-efficiency as a first-class systems objective rather than a secondary effect of hardware power management.

Source: https://www.emergentmind.com/topics/ecosched