Last-K Preemption Scheduling
- Last-K Preemption is a scheduling model that allows only the most recent K task graphs to be reallocated, balancing adaptability with reduced computational overhead.
- It employs heuristics such as HEFT to reassign tasks within a bounded recency window, substantially boosting makespan performance and node utilization.
- Empirical evaluations demonstrate that moderate K values (5–10) achieve 90–98% of full preemption gains while keeping scheduler runtime overhead below 20%.
Last-K Preemption is a controlled scheduling model for dynamic task graph allocation in distributed computing systems. Unlike fully preemptive strategies, which reschedule all active tasks when new dependencies arise, or non-preemptive schemes, which fix all prior allocations, Last-K Preemption permits selective rescheduling: only the most recent task graphs are eligible for preemption on the arrival of each new task graph. This approach balances adaptability, performance, and computational overhead, offering substantial improvements in makespan and resource utilization without incurring the fairness penalties and runtime costs of full preemption (Khodabandehlou et al., 3 Feb 2026).
1. Formal Model and Scheduling Semantics
Given a sequence of task graphs
where each with tasks , dependencies , and arrival times , Last- Preemption fixes an integer parameter .
On arrival of the -th graph 0:
- The set of graphs eligible for preemption is defined as:
1
- All tasks in 2 are unscheduled (de-allocated) and marked pending. Earlier graphs 3 remain fixed.
- The scheduler reallocates all pending tasks from 4 using a specified heuristic (e.g., HEFT, Min-Min).
This design enables controlled intervention in the schedule, revisiting only a recency window of size 5, thereby limiting disruption to already-executed graphs.
2. Underlying Computational Problem
The computational instance involves a compute network 6 with 7 nodes, homogeneous or heterogeneous, each 8 characterized by speed 9. Each task 0 has compute cost 1; dependencies 2 have communication cost 3. Task 4 on node 5 incurs execution time 6; communication between 7 (on 8) and 9 (on 0) takes 1.
Subject to precedence, communication, and non-overlap constraints, the objective is to minimize total completion time (makespan):
2
where 3 are start and finish times of task 4.
3. Algorithmic Structure
At every graph arrival, the Last-5 protocol interleaves task (un)scheduling with heuristic reallocation within a bounded window. The pseudocode instantiates as:
8
The specific behavior of ExtractNextTask and SelectBestNode inherits from the selected scheduling heuristic (HEFT, CPOP, etc.).
4. Analytical Complexity and Overheads
Workspace and algorithmic costs scale with 6, the recency parameter. For total pending tasks 7 across the preempted graphs and the new arrival:
- Per scheduling event: 8, where 9 is the average number of tasks per graph, and 0.
- For 1 (i.e., full preemption), complexity degenerates to 2.
- Space overhead corresponds to 3 for maintaining the task states of the preempted graphs.
- Operational preemption cost is linear in 4: if task (de-)allocation costs 5 per task graph, total event cost is approximately 6.
A plausible implication is that while the protocol is scalable for small to moderate 7, high 8 values can negate the runtime advantages of partial preemption.
5. Empirical Evaluation and Metrics
Evaluation comprises diverse workloads:
- Synthetic: 100 graphs (4 shapes: out-tree, in-tree, fork-join, chain; Gaussian weights)
- RIoTBench: 100 DAGs (ETL, Predict, Stats, Train)
- WFCommons: 50 scientific workflows (Epigenomics, Montage, etc.)
- Adversarial: 100 out-trees with heavy root, CCR = 0.2
Schedulers tested include HEFT, CPOP, Min-Min, Max-Min, and Random, with three preemption regimes: non-preemptive (NP), fully preemptive (P), and Last-9 partial preemptive (0P).
Key metrics:
- 1 (Total Makespan)
- Mean Makespan: 2
- Mean Flowtime: 3
- Node Utilization: 4
- Scheduler Runtime (relative overhead)
Experimental protocol utilizes the SAGA simulator on 16 heterogeneous nodes, each experiment averaged over 10 random seeds.
6. Quantitative Trade-offs and Performance Analysis
Empirical results demonstrate that Last-5 Preemption achieves a substantial fraction of the performance gains obtainable with full preemption, with reduced scheduling and computational costs.
| Scheduler | Makespan | MeanMakespan | MeanFlowtime | Utilization | Runtime |
|---|---|---|---|---|---|
| NP-HEFT | 1.60 | 1.40 | 1.00 | 0.75 | 1.00 |
| 5P-HEFT | 1.03 | 1.12 | 1.05 | 0.90 | 1.10 |
| 10P-HEFT | 1.01 | 1.10 | 1.08 | 0.92 | 1.15 |
| 20P-HEFT | 1.00 | 1.10 | 1.10 | 0.94 | 1.25 |
| P-HEFT | 1.00 | 1.15 | 1.50 | 0.95 | 1.50 |
Last-5 or Last-10 Preemption achieves 90–98% of full preemption's makespan and utilization gains. Mean flowtime is lowest for NP (no task interruption), highest for full preemptive, and intermediate for moderate 6. Node utilization rises from ~80% (NP) to ~95% (P), with Last-5 in the 90–92% range. Scheduler runtime overhead checks in at 10–20% beyond NP for moderate 7, compared to 50% overhead under full preemption.
Varying 8 delineates the trade-off:
- 9: low (<5%) runtime overhead, but only 50–60% of full preemptive improvement.
- 0: ~90% of makespan/utilization gain, flowtime up by ~5%, scheduler runtime up ~10%.
- 1: diminishing returns, with costs rising near-linearly in 2.
7. Design Recommendations and Practical Implications
Controlled preemption with 3 in the 5–10 range is recommended to attain near-optimal makespan and utilization, while limiting fairness degradation (flowtime increase 410%) and algorithmic overhead (scheduler runtime 520%). For operational deployment, an adaptive policy is advised:
6
where 7 denotes the expected number of graphs in the application session. This setting robustly mediates between adaptability to workload dynamics and schedule stability, accommodating both scientific workflows and streaming analytics scenarios. The Last-K Preemption model provides a principled and empirically effective mechanism for dynamic, fair, and efficient resource management in task graph scheduling contexts (Khodabandehlou et al., 3 Feb 2026).