---
title: Adaptive Candidate Scheduler
url: https://www.emergentmind.com/topics/adaptive-candidate-scheduler
type: topic
---

# Adaptive Candidate Scheduler

An adaptive candidate scheduler is, in the sense suggested by several scheduling systems published across planning, systems, and machine learning, a mechanism that maintains a set of candidate actions and adaptively selects among them online using current state, predicted outcomes, or observed feedback. The candidates may be planners, expert schedulers, machine partitions, subjob variants, queue assignments, forwarding thresholds, tensor-program schedules, or stopping points along a denoising trajectory. What unifies these designs is a move away from a static rule toward a closed loop in which alternatives are generated or enumerated, scored under an explicit objective, and then enacted through a runtime control path [1811.00210][2512.18894][2511.11628][2601.21758][2605.27947].

## 1. Scope, lineage, and recurring forms

The published record shows that the idea emerged in multiple communities under different names. In automated planning, a two-stage scheduler selects an initial planner from a portfolio \(P=\{1,\dots,D\}\), runs it for \(T/2\), and may switch at halftime using a conditional failure model [1811.00210]. In heterogeneous runtime systems, schedulers choose among hardware configurations, leader-core/width pairs, or thread partitions by combining phase information with online performance estimates [1903.07038][1905.00673][2112.09509]. In operating systems and cluster managers, recent work replaces a single fixed policy with adaptive routing among expert schedulers or simulated policies [2511.11628][2512.18894]. Related constructions also appear in workflow submission control, tensor-program search, multi-device inference, O-RAN xApp coordination, LLM serving, and robot control [2401.09733][2211.11172][2412.04147][2504.06867][2508.03258][2605.27947].

This suggests that “adaptive candidate scheduler” is best understood as a cross-domain pattern rather than a single named algorithm.

| System | Candidate set | Online selection mechanism |
|---|---|---|
| GNN planner scheduler [1811.00210] | planners \(P=\{1,\dots,D\}\) | initial selection plus halftime switch |
| SchedTwin [2512.18894] | policies \(\{P_1,\dots,P_k\}\) | parallel what-if simulation |
| ASA, Mixture-of-Schedulers [2511.11628] | expert schedulers | ensemble voting plus mapping table |
| ARMS [2112.09509] | partitions \(R=[LR,W]\) | minimize online cost |
| JASDA [2510.14599] | feasible subjob variants | weighted interval scheduling |
| EWSJF [2601.21758] | request queues and head-of-line requests | density-weighted scoring |
| SANTS [2605.27947] | stopping and progression choices on a noise trajectory | cumulative hazard threshold |

## 2. Operational loop

A recurrent control loop begins with state acquisition. **SchedTwin** maintains \(Q(t)\), the set of waiting jobs with arrival times, size, and user-estimated walltimes; \(R(t)\), the vector of currently free or occupied nodes; and \(E(t)\), the virtual event queue of predicted job completions. PBS hooks `queuejob`, `runjob`, and `jobobit` push real-time metadata into a Redis stream, and the twin classifies each event as arrival, start, or completion [2512.18894]. **ASA** collects normalized CPU, memory, disk, process, scheduling, and network metrics; the paper lists 30+ such metrics and uses them as the input to an ensemble of XGBoost, Random Forest, and SVM classifiers [2511.11628]. **MultiTASC++** collects per-device SLO satisfaction rates over rounds of duration \(T\), and **SANTS** observes the video representation \(z_t\) and current noise level \(\nu_t\) at each decision point [2412.04147][2605.27947].

The next step is candidate generation or enumeration. In some systems the candidate pool is fixed in advance. **SchedTwin** clones a CQSim-based simulator once per candidate policy \(P_i\), while **ASA** selects from a pre-configured mapping table of expert schedulers [2512.18894][2511.11628]. In others, candidates are created dynamically. **JASDA** receives an announced window \(w^*=(s_k,c_k,t_{\min},\Delta t)\), then each job enumerates feasible subjob variants \(v_{ik}^{w^*}\) whose predicted RAM demand satisfies the probabilistic safety condition
\[
\Pr\!\bigl(\max_{t\in I(v)} RAM_i(t)>c_k \mid FMP_i\bigr)\le \theta .
\]
Silent jobs simply produce no bids [2510.14599]. **EWSJF** discovers contiguous prompt-length intervals by Refine-and-Prune, then may create a “bubble queue” when an arrival falls into a gap between existing queues [2601.21758].

After candidate creation, the scheduler computes scores or estimates. This may be done by predictive simulation, learned classification, cost models, bandit-style weights, or RL value estimates. The action phase is explicit in several systems: **SchedTwin** invokes PBS’s `qrun <jobid>` for the selected jobs; **ASA** swaps schedulers through Linux’s `sched_ext` interface; the planning scheduler either continues \(p_1\) or aborts it and runs \(p_2\); **MultiTASC++** pushes updated thresholds \(c_i\) back to devices; and **SANTS** either stops and emits an action chunk or advances further along the noise trajectory [2512.18894][2511.11628][1811.00210][2412.04147][2605.27947].

Feedback closes the loop. **SchedTwin** corrects early or late finishes on completion events, **ASA** augments training data with switching overhead and later fine-tunes on live causal effects of switching, **JASDA** computes feature-level post-execution errors and a reliability coefficient \(\rho_{J_i}\), and **SmartLLMs Scheduler** retrains success and cost predictors from an inspected subset while also adapting the cache threshold \(\tau\) [2512.18894][2511.11628][2510.14599][2508.03258].

## 3. Decision rules and objective functions

The mathematical forms vary, but all of them formalize a choice among candidates. In **SchedTwin**, the default policy selector computes
\[
\mathrm{Score}(P_i)=0.25\cdot \max W_i+0.25\cdot \avg W_i+0.25\cdot \max SD_i+0.25\cdot \avg SD_i,
\]
where \(SD_j=(W_j+s_j)/s_j\), then selects
\[
P^*=\arg\max_{i=1..k}\mathrm{Score}(P_i).
\]
The simulator then returns the first set of job-start events immediately after time \(t\) [2512.18894].

In **ASA**, every classifier emits a probability vector \(P_t=[p_{t,1},\dots,p_{t,C}]\). The runtime smoother aggregates the last \(W\) time-steps with exponential decay:
\[
A_i(t)=\sum_{k=1}^W \alpha^{W-k}\cdot \max(p_{t-W+k,i}-\theta,0),
\qquad
\hat C(t)=\arg\max_i A_i(t).
\]
The voted class is mapped to an expert scheduler by a machine-specific table \(M\) that was calibrated offline to account for switching overhead [2511.11628].

The two-stage planning scheduler uses a different but closely related rule. It first chooses
\[
p_1=\arg\min_{j\in P} f_j(G),
\]
runs \(p_1\) for \(T/2\), and if unsolved computes \(g_j(G,p_1)\). At halftime it switches only when
\[
\min_{j\in P} g_j(G,p_1) < g_{p_1}(G,p_1).
\]
This is an explicit candidate-comparison rule conditioned on partial execution evidence [1811.00210].

Candidate scoring also appears in resource-molding systems. **ARMS** defines
\[
\mathrm{Cost}(t,s,R)=T_{t,s}(LR)\times W
\]
for a task type \(t\), Software Topology Address \(s\), and partition \(R=[LR,W]\), and chooses the partition minimizing this quantity [2112.09509]. The **PTT** scheduler in XiTAO uses a related score \( \mathrm{PTT}[c][w]\times w \) and updates each entry with a moving average
\[
\mathrm{PTT}[c][w]\leftarrow \frac{4\times \mathrm{old}+t_{\mathrm{new}}}{5}
\]
after each execution [1905.00673].

Other adaptive schedulers expose different mathematical objects but retain the same candidate-selection structure. **Adaptive Scheduling Algorithm** for workflow queue-wait estimation maintains probabilities over candidate waits \(A=\{a_1,\dots,a_m\}\) and updates them by
\[
p_{t+1,i}\propto p_{t,i}\exp(-\gamma_t L_i),
\]
a Hedge-style rule [2401.09733]. **ATS** assigns task-sampling weights from query loss and support-query gradient similarity and trains its scheduler by a bi-level objective with a REINFORCE update on \(\phi\) [2110.14057]. **SANTS** accumulates hazard increments \(\Delta H_t=\lambda_\theta(z_t,\nu_t)\), forms \(H_t=\sum_{i=1}^t \Delta H_i\) and \(F_t=1-\exp(-H_t)\), then stops at test time when \(F_t\ge \eta\) [2605.27947]. **EWSJF** prioritizes the head-of-line request \(r\) in queue \(q\) using
\[
\Phi(r,q)=qf \times \left(w_{\mathrm{base}}+w_{\mathrm{urg}}\frac{W_t}{C_{\mathrm{prefill}}(b)}+w_{\mathrm{fair}}\log(b+1)\right),
\]
and tunes its parameters by Bayesian meta-optimization [2601.21758].

## 4. Integration paths and systems realizations

The implementation literature emphasizes that adaptive candidate selection is not merely an abstract optimizer; it is usually embedded into an existing control plane. **SchedTwin** is a “simulation-in-the-loop” digital twin for PBS-managed clusters. PBS events push to Redis within milliseconds, the synchronization and simulation phases execute within \(O(1\text{–}3\,\mathrm{s})\) per scheduling cycle on a 32-node Docker cluster, and no modification to PBS core logic is required because enforcement uses only `qrun` [2512.18894].

**ASA** is implemented around Linux’s `sched_ext` BPF-based extension. The Action module runs in user space and uses a netlink or ioctl call to unregister the current BPF scheduler and load the selected expert’s BPF object. To minimize oscillation it uses a cooldown interval, with a recommended minimum inter-switch period of \(4\,\mathrm{s}\). Reported overheads are CPU overhead \(1.45\%\) of one core, memory overhead \(\sim 300\,\mathrm{MB}\), and decision latency average \(18.3\,\mathrm{ms}\) with \(P99<380\,\mathrm{ms}\) [2511.11628].

Some systems place the adaptive scheduler above, rather than inside, the executor. **EWSJF** runs a strategic loop every \(5\text{–}15\,\mathrm{min}\) to update queue boundaries and meta-parameters, and a tactical loop every few ms to assign arrivals, compute \(\Phi(r,q)\), and build batches in \(O(k)\) time with \(k\le 32\) [2601.21758]. **MultiTASC++** updates forwarding thresholds once per round of duration \(T\) and can switch the heavy server model according to a threshold-based signal \(S(\mathcal C)\) [2412.04147]. **SmartLLMs Scheduler** routes cache misses to one of several LLMs using predicted performance-to-cost ratio \(r_{i,j}=\hat p_{i,j}/\hat c_{i,j}\), then retrains the classifier and regressor periodically when \(t \bmod Q=0\) [2508.03258].

Decentralized realizations are also represented. **JASDA** turns each announced execution window into a weighted interval scheduling instance over submitted variants. Its per-iteration time complexity is
\[
\mathcal O(M)\,t_{\mathrm{gen}}+\mathcal O(M\log M),
\]
and the message complexity is \(|V_i|\) bids per job per round [2510.14599]. In O-RAN, the xApp conflict-mitigation scheduler observes RAN state and selects a binary activation vector \(a_t=[\mu_t^1,\dots,\mu_t^N]\) over pre-trained xApps, optimized by an A2C actor-critic [2504.06867].

## 5. Empirical behavior across domains

The empirical literature reports repeated gains over static baselines, although the measured objective differs by domain. In automated planning, the two-stage adaptive scheduler increased coverage on the IPC-2018 test set from \(87.6\%\) to \(89.7\%\) for GCN and from \(81.4\%\) to \(83.0\%\) for GG-NN; across domain-preserving and random splits, GCN adaptive coverage reached \(91.1\%\pm 3.8\) and \(92.1\%\pm 3.2\), compared with \(85.6\%\pm 5.5\) and \(87.2\%\pm 3.5\) for the single-planner variant [1811.00210].

In heterogeneous runtime and HPC settings, the reported gains are often multiplicative. The XiTAO performance-based scheduler achieved up to \(3.25\times\) higher throughput than homogeneous work stealing on Jetson TX2, with sequential-DAG speedups of \(3.3\times\) for MatMul, \(2.5\times\) for Sort, \(2.2\times\) for Copy, and \(2.7\times\) for Mixed [1905.00673]. **ARMS** reports up to \(3.5\times\) performance gain over prior locality-aware schemes and up to \(10\times\) fewer L2 misses in stencil and MatMul [2112.09509]. **Astro** was faster than GTS in 6 of 8 benchmarks and energy-saving in 5 of 8, with maximum speedup \(\approx 10\text{–}12\%\) and maximum energy saving \(\approx 12\text{–}18\%\) [1903.07038]. For workflow submission control, **ASA -- The Adaptive Scheduling Algorithm** reported up to \(10\%\) reductions in average workflow queue waiting times and \(2\%\) reductions in makespan, while core-hour usage stayed within \(1\text{–}2\%\) of the minimal [2401.09733]. **SchedTwin** achieved radar area \(1.86\), compared with \(1.67\) for WFP, \(0.31\) for SJF, and \(0.00\) for FCFS, corresponding to an \(11.4\%\) increase over WFP, while keeping overhead to a few seconds per cycle [2512.18894].

In operating systems and online services, adaptive routing among candidates is reported to improve both responsiveness and throughput. **ASA, Mixture-of-Schedulers** outperformed Linux’s default EEVDF in \(86.4\%\) of \((\text{scenario},\text{VM})\) runs with mean improvement \(+8.83\%\) and \(95\%\) CI \([7.08\%,10.59\%]\); it picked the single best expert in \(45.4\%\) of cases and ranked in the top three in \(78.9\%\) of cases, with all win-rate differences against EEVDF significant at \(p<0.01\) across 1680 runs [2511.11628]. **EWSJF** improved end-to-end throughput by over \(30\%\) and reduced average Time-To-First-Token for short requests by up to \(4\times\) compared to FCFS; in one \(30\,\mathrm{k}\)-request mixed workload, throughput increased from \(8.45\) to \(12.58\) req/s and from \(90.4\) to \(168.2\) tok/s while average short-request TTFT decreased from \(120\,\mathrm{ms}\) to \(30\,\mathrm{ms}\) [2601.21758]. **SmartLLMs Scheduler** reported an average performance improvement of \(198.82\%\) and an average processing time reduction of \(63.28\%\) on log parsing and code generation [2508.03258].

In ML and control pipelines, adaptive candidate scheduling appears both in training and inference. **ATS** improved performance on miniImageNet and a drug discovery benchmark by up to \(13\%\) and \(18\%\), respectively, under noise and limited budgets [2110.14057]. **HARL** improved tensor-operator performance by \(22\%\) and search speed by \(4.3\times\) over the state-of-the-art auto-scheduler [2211.11172]. **MultiTASC++** maintained a satisfaction rate of \(95\%\pm 1\) percentage points for \(0\text{–}100\) devices while throughput scaled to \(\sim 4{,}500\) sps at 100 devices and accuracy stayed near the full-cascade optimum \((\sim 78\%)\) in the homogeneous Sony C5 plus InceptionV3 setting [2412.04147]. **SANTS** reached \(94.4\%\) overall success on RoboTwin 2.0 with \(523.7\,\mathrm{ms}\) latency, compared with \(91.8\%\) and \(2868\,\mathrm{ms}\) for full-denoising WAM, and on seven real-robot tasks achieved \(73.1\%\) mean success with \(581.3\,\mathrm{ms}\) latency versus \(65.7\%\) and \(2769\,\mathrm{ms}\) [2605.27947]. In O-RAN conflict mitigation, the extended A2C scheduler with four xApp candidates achieved \(\approx 0.99\) normalized throughput in high-load/high-mobility settings, while conflict rate fell from \(\sim 30\%\) in the uncoordinated case to \(<5\%\), and Jain’s fairness index improved by \(\sim 8\%\) in mid-load regimes [2504.06867].

## 6. Limitations, misconceptions, and open directions

A common limitation is dependence on the fidelity of the underlying predictor or model. **SchedTwin** currently relies on user-estimated walltimes, and its model accuracy degrades if estimates are very poor; its simulator also assumes instantaneous scheduling and no failures [2512.18894]. **JASDA** depends on timely variant generation, calibrated policy weights \((\lambda,\alpha_i,\beta_j)\), and reliable TRP/FMP estimation; the paper states that its clearing is locally optimal per window but globally myopic, and no formal competitive ratio is given [2510.14599]. **SmartLLMs Scheduler** requires periodic inspection and retraining to maintain predictor quality, while **ATS** explicitly addresses the fact that high-loss tasks may be genuinely useful or merely noisy [2508.03258][2110.14057].

Switching cost and stability are recurrent concerns. **ASA** introduces shadow schedulers, BPF preloading, and a cooldown interval to prevent oscillation, and recommends fallback to EEVDF if decision latency exceeds \(500\,\mathrm{ms}\) or classifier confidence is low \((<\theta)\) [2511.11628]. **MultiTASC++** uses conservative threshold updates and multiplicative scaling to stabilize satisfaction-rate control under changing device participation [2412.04147]. **SANTS** adds an explicit penalty on redundant video-state updates so that the scheduler is optimized for downstream action quality rather than intermediate video fidelity [2605.27947].

A frequent misconception is that adaptivity necessarily means training a single monolithic scheduler end to end. The literature does not support that generalization. Some systems are explicitly portfolio-based: the planning scheduler chooses among planners, **ASA** chooses among expert schedulers, **SchedTwin** chooses among simulated policies, and the O-RAN framework schedules pre-trained xApps “without requiring training xApps together or further xApp re-training” [1811.00210][2511.11628][2512.18894][2504.06867]. Others adapt over candidate resource shapes, queue partitions, or stopping depths rather than over whole schedulers [2112.09509][2601.21758][2605.27947]. This suggests that the defining property is not a specific learning architecture but the runtime comparison of multiple candidate actions under a state-dependent objective.

Open directions are stated explicitly in several papers. **SchedTwin** identifies multi-resource scheduling, fault-aware scheduling, elastic scaling, ML-based runtime predictors, and dynamic refinement of the policy pool [2512.18894]. **ASA** emphasizes rapid porting to new hardware by retraining only the mapping table \(M\) in Stage 3 [2511.11628]. **JASDA** highlights richer window selection strategies and controlled information visibility for strategic workloads [2510.14599]. Across the literature, a plausible implication is that future adaptive candidate schedulers will continue to separate candidate generation, candidate evaluation, and enforcement, while pushing more of the uncertainty handling into online feedback and post-deployment calibration.

Source: https://www.emergentmind.com/topics/adaptive-candidate-scheduler