Dominant resource fairness

For each user, divide allocated CPU by total CPU capacity, allocated memory by total memory capacity, and similarly for other resource types. The largest of these fractions is that user’s dominant share. The dominant resource can differ between users and can change as demand changes. Comparing raw values such as ten CPUs and twenty GiB has no meaningful fairness interpretation. Normalization removes the units while preserving which fraction of each shared resource the user occupies.

Equal-weight DRF grows feasible allocations according to dominant-share fairness, with task demands commonly modeled as fixed resource proportions. Weighted policies can intentionally give different entitlements. The original model’s properties depend on its assumptions, including the resources and demand model being allocated. Integer jobs, placement restrictions, heterogeneous accelerators, changing demand, and non-preemptible work complicate practical allocation. A cluster plugin described as DRF-inspired should state which definition and guarantees survive those differences rather than inheriting every theorem from a name.

A CPU-heavy user may receive fewer tasks than a memory-heavy user while their dominant shares match. Equal task counts are not the definition, although some symmetric examples happen to produce them. Work through the full resource constraints before claiming an equal-share solution fits. A candidate that balances dominant shares while overallocating memory is invalid. Conversely, unused capacity can remain when a bottleneck resource prevents further growth under the workload’s fixed proportions.

Resource fairness and useful progress also differ. Two users with the same GPU share may obtain different training throughput because of hardware efficiency, parallel scaling, or communication. Time-sharing accelerators introduces checkpoint and interference costs. A service policy may combine resource entitlements with separate latency classes or admission rules, but those changes should be explicit. Do not silently mix an inference deadline objective with an equal-share training policy and then describe the result as satisfying both without evidence.

Record normalized usage, configured weights, runnable demand, and the constraints preventing extra allocation. A user below its entitlement may simply lack feasible work, or may be blocked by a device flavor rather than unfair queue ordering. Check that a team cannot improve its entitlement merely by splitting one identity into many uncontrolled identities. Admission and identity policy therefore belong alongside the allocation algorithm. Evaluate fairness over the intended time window; an instantaneous snapshot can misrepresent a long-running non-preemptible job’s history.

The vector lab clarifies the difference between vector length and dominant component. Reset, set angle to 0 degrees and magnitude to 1, predict the maximum normalized component, then Step. For a fresh run, Reset and explicitly set angle to 45 degrees and magnitude to 1, predict the maximum again, then Step. Both vectors have unit length, but their largest components differ. Interpret the axes as two normalized resource allocations only. The instrument has one user, no weights, and no DRF allocation procedure.