EcoSched: Eco-Aware Scheduling

Updated 5 July 2026

EcoSched is an eco-aware scheduling framework that uses empirical profiling to minimize energy per operation while bounding runtime increases.
In supercomputing centers, EcoSched achieved an average 21.5% power reduction with a minimal 3.8% runtime increase, and in multi-GPU systems, it reduced energy by up to 14.8%.
The design integrates non-intrusively with existing systems, leveraging historical performance data to balance energy, delay, and idle resource metrics.

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 (Kiselev et al., 2021). 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 (Zheng et al., 19 Apr 2026). 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 (Kiselev et al., 2021). 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 (Zheng et al., 19 Apr 2026).

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 (Kiselev et al., 2021). 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 (Kiselev et al., 2021).

Given program $p$ and system $i$ , let $T_{p,i}$ be runtime and $C = \frac{W}{P},$ 0 be energy per operation. With

$C = \frac{W}{P},$ 1

the admissible systems satisfy

$C = \frac{W}{P},$ 2

and the scheduler chooses

$C = \frac{W}{P},$ 3

This is a constrained optimization, not a weighted sum: minimize $C = \frac{W}{P},$ 4 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 = \frac{W}{P},$ 5 and $C = \frac{W}{P},$ 6 values, selects the system with minimal $C = \frac{W}{P},$ 7 satisfying the $C = \frac{W}{P},$ 8 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 (Kiselev et al., 2021).

The slowdown bound can be administratively fixed or automatically inferred from the user walltime request. When a prior runtime $C = \frac{W}{P},$ 9 is known and does not exceed $W$ 0, the paper gives

$W$ 1

This makes $W$ 2 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 (Zheng et al., 19 Apr 2026). 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 (Zheng et al., 19 Apr 2026). 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 $W$ 3 and GPU count $W$ 4, it derives a normalized runtime estimate $W$ 5, measures average busy power $W$ 6, and defines a normalized energy proxy

$W$ 7

Modes with excessive slowdown are filtered using a slowdown tolerance $W$ 8, so the scheduler does not pursue large energy reductions through arbitrarily poor performance.

At each scheduling event, an action $W$ 9 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 $P$ 0 denoting the number of modes in the action and $P$ 1 the number of GPUs it consumes,

$P$ 2

$P$ 3

and the score is

$P$ 4

The scheduler selects

$P$ 5

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 (Zheng et al., 19 Apr 2026).

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 $P$ 6 subject to a user- or administrator-defined slowdown bound $P$ 7 (Kiselev et al., 2021). 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 $P$ 8 (Zheng et al., 19 Apr 2026). 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 (Kiselev et al., 2021). 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 (Zheng et al., 19 Apr 2026). 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 (Kiselev et al., 2021). 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 (Zheng et al., 19 Apr 2026). 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 (Kiselev et al., 2021). In the multi-GPU setting, slight per-application slowdowns can shorten workload makespan because freed GPUs enable beneficial coscheduling (Zheng et al., 19 Apr 2026). The underlying mechanism is different in each case, but the principle is the same: local performance maximization is not equivalent to workload-level efficiency.

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 (Nouiri et al., 2019). 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 (Jiang et al., 2024). For workflow DAGs with fixed mapping and deadline, CaWoSched addresses carbon-aware scheduling against interval-based green-energy availability (Schweisgut et al., 11 Jul 2025). 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 (Ronco, 2022).

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.