Preemption
What does taking a resource back cost, and which task should you kill?
Preemption is the only way to subdivide a resource that cannot be shared in time. Its cost depends on what you do with the victim's state:
| Option | Cost |
|---|---|
| Kill it | You burn all work done so far |
| Checkpoint it (save its state, resume later) | state size ÷ write bandwidth |
| Migrate it (move it to another machine) | state size ÷ network bandwidth, plus the deadline that imposes |
Preemption breaks the work-conservation assumption from Work is conserved. Total work is no longer fixed: it grows by the lost progress. Preemption is positive-sum only when the queueing delay it saves the beneficiary is larger than the work it destroys in the victim.
This gives an immediate rule: if you must kill, kill the youngest task (least sunk work). That conflicts with the SRPT instinct to preempt the one with the most remaining work. The tension has no universal answer. It depends on which cost is larger in your workload, and checkpointability is what lets you dodge it.
Preemption relocates delay with friction. The friction is the victim's unsaved progress.