Partitions, QOS, fair share, and honest requests
Audience: Both users and administrators · Reviewed: 2026-10-04
Version and teaching scope
Use documentation matching your installed release and local policy. Check sinfo --version; upstream documentation identified itself as 26.05 at review. Paths, partitions, accounts, modules, memory, MPI, GPUs and services are site-specific. Example programs beginning ./ must already exist. These are teaching examples, not a validated deployment recipe or evidence that a cluster was modified.
Partition, QOS and account
A partition groups eligible nodes and sets access or time constraints. A QOS can carry priority, resource limits, or preemption policy. An account identifies the project charged for usage. None of these names is universal: gpu, short, or normal may not exist at your site.
Priority and backfill
Fair share is one possible input to multifactor priority. It balances usage against configured shares and policy over time; it is not a promise of a start time. Age, job size, QOS, partition factors, reservations, and resource fit may also matter. Backfill can start suitable shorter work when doing so will not delay protected higher-priority work. Artificially large time or memory requests can reduce scheduling opportunities.
Useful read-only exploration:
Output availability depends on policy and installed plugins. Ask administrators which account/QOS combinations you may use rather than guessing premium QOS names.
Translate application layout into resources
For example, four MPI ranks with eight threads each need 32 allocated CPUs in the intended layout; they do not mean 32 MPI ranks. A Slurm CPU can correspond to a core or hardware thread depending on site configuration. --mem requests memory per node, while --mem-per-cpu scales with allocated usable CPUs. Choose a coherent model, check local defaults, and leave reasonable headroom informed by measurements.
Test policy boundaries
Administrators should test policies with a small matrix: authorized user, unauthorized account, excessive time, excessive memory, and concurrent-job limits. A resource denial should produce a documented reason and a clear route for requesting an exception.
Official sources
Previous: Read Slurm configuration as a system · Learning path · Next: Submit, inspect, and stop a job