Responsible computeRunning track

Fair-share scheduling

Read it in Chapter 2 · checkpoint +50 XP →

Scheduler policies that balance access between teams based on what they're entitled to and what they've recently used.

On a shared cluster, "first come, first served" lets one team's 1,000 queued jobs starve everyone else. Fair-share scheduling (e.g. Slurm's multifactor priority) lowers the priority of users and accounts that recently used more than their share, with usage decaying over time.

The ingredients

  • Shares: each account's entitlement, often matching funding or team size.
  • Usage decay: a half-life (e.g. 7 days) so past usage is forgiven gradually.
  • QOS limits: caps on concurrent GPUs, wall time or job count, so no single job blocks the cluster.
  • Preemption: low-priority or opportunistic jobs can be checkpointed and requeued when priority work arrives. This only works if jobs checkpoint well.

Fairness is also about transparency: publish usage per team, queue wait times and energy, so allocation debates use data instead of anecdotes.

Related

Sources & further reading

Written for LazyLab in our own words; sources are cited for depth and verification.