What makes a resource dominant?

It has the largest allocated fraction of that resource's total capacity for the user. The comparison uses shares, not raw units.

Does DRF always give everyone exactly the same dominant share?

No. Demand limits, resource bottlenecks, weights and indivisible allocations can affect the result.

Does DRF decide business priorities?

Not by itself. Basic DRF assumes a fairness policy; weighted entitlements and priority rules must be chosen and explained separately.

AI Glossary / Data engineering and architecture / Advanced

Dominant resource fairness

Definition

Dominant resource fairness, or DRF, is a resource-allocation rule that extends max-min fairness to several resource types. It compares each user's largest proportional resource allocation, called the dominant share, and aims to increase the smallest such shares subject to feasible demand and capacity.

What it means

A cluster may provide processors, memory and other resources. One workload can be processor-heavy while another needs relatively more memory. Counting equal numbers of tasks or giving equal amounts of memory does not necessarily provide a meaningful balance between them.

DRF converts allocations into fractions of the available capacity. A user's dominant resource is the one on which its allocation occupies the largest fraction. It is not necessarily the resource with the largest raw number: processor counts and gigabytes cannot be compared directly.

Fairness here has a precise technical meaning. It is not a statement that every business objective, urgency level or project value has been considered. Weighted versions can represent different entitlements, but choosing those weights is a policy decision outside the basic arithmetic.

How it works

For each user, divide the amount allocated of each resource by that resource's total capacity. Take the largest fraction as the user's dominant share. An allocation process gives preference to eligible demand with a low dominant share while respecting every resource limit.

In the simplest setting with sufficient demand, this tends to equalize dominant shares. Exact equality is not universal: a user may finish requesting resources, a bottleneck may prevent additional useful allocation, or tasks may be indivisible. A real scheduler must also decide how to handle placement, priorities and running tasks.

The original research establishes desirable fairness and incentive properties under its model. These are not guarantees against every practical manipulation or failure. Heterogeneous servers, placement constraints and changing demands require additional consideration; follow-on research explicitly studies extensions beyond the original pooled-resource setting.

Three practical examples

A shared analysis cluster compares processor-heavy simulations with memory-heavy aggregation jobs using proportional resource shares rather than task counts alone.
A platform team examines whether a scheduler's configured resource calculator considers both processor and memory demand instead of only one dimension.
An AI infrastructure team studies multi-resource fairness when different jobs need different combinations of accelerator, processor and memory capacity, while separately checking placement constraints.

Think of it this way

Think of a workshop sharing both bench space and power capacity. One team mainly needs benches; another mainly needs power. Comparing each team's largest fraction of the shared resources gives a more informative starting point than counting machines alone.

The analogy does not make the fairness decision morally complete. Real workshops have deadlines and safety limits, while DRF is a defined allocation rule under specified demands and constraints.

Worked example

Consider a fictional pool with 12 processor units and 24 gigabytes of memory. Each task for user A requires 2 processors and 2 gigabytes; each task for user B requires 1 processor and 8 gigabytes. Assume equal entitlements and enough tasks.

One A task uses 2/12 of processors and 2/24 of memory, so its dominant share is 1/6. One B task uses 1/12 and 8/24, so its dominant share is 1/3. Two A tasks therefore contribute the same dominant share as one B task.

An allocation of four A tasks and two B tasks uses 10 processors and all 24 gigabytes. A's dominant share is 8/12, or two-thirds; B's is 16/24, also two-thirds. Two processors remain unused, but neither user can run another complete task without more memory. Equal dominant shares do not imply full utilization of every resource.

Illustrative case study

Fictional case: a research organization gives each team the same number of concurrent task slots. Teams with large memory requirements repeatedly encounter capacity limits, while other teams leave some assigned memory unused.

The platform group evaluates a DRF-based policy using recorded demand profiles. It reports each team's processor and memory shares, job waiting time and unused capacity. It also discovers that some jobs require a particular accelerator type, so an apparently feasible pooled allocation may not fit the actual machines.

The evaluation records these placement constraints and compares weighted entitlements separately from measured utilization. It produces a clearer allocation policy, not a claim that DRF always maximizes completed jobs or removes the need for operational scheduling decisions.

Common misconceptions and mistakes

Common errors include adding resource quantities with different units, identifying the dominant resource from raw numbers and assuming fairness means equal task counts. A task needing twice the relevant dominant share may receive fewer simultaneous task allocations.

Another mistake is interpreting Pareto efficiency as every resource being fully occupied or total throughput being globally maximized. These are different concepts. Also, a theoretical strategy-proofness result depends on the permitted strategies and demand model; it does not automatically cover fake identities, unmeasured resources or arbitrary changes to a production scheduler.

Business use

DRF helps businesses make resource-sharing policy explicit when teams have different workload shapes. It can provide a better comparison than a single resource quota, but the resource totals, measurements and entitlement weights must be credible.

Evaluation should include per-team progress and wait times as well as aggregate utilization. For AI workloads, hardware compatibility, data locality and jobs requiring several devices together can constrain placement. A fairness formula should be assessed as part of the scheduling system rather than presented as a complete capacity-management solution.

Check your understanding

A user has 4 of 20 processor units and 30 of 100 gigabytes of memory. Which resource is dominant, and what is the dominant share?

Answer: Memory is dominant: its share is 30 percent, compared with 20 percent of processors. The dominant share is therefore 30 percent.

Related terms

Max-min fairness
resource allocation
cluster scheduling
dominant share
weighted fairness
capacity
resource fragmentation
heterogeneous computing

Learn next

calculate dominant shares for three small workload profiles, then compare equal task counts with equal dominant shares. Study placement constraints next, because a feasible allocation in an aggregated pool may not fit any available physical server.

Sources

Ghodsi and colleagues, Dominant Resource Fairness: Fair Allocation of Multiple Resource Types: https://static.usenix.org/event/nsdi11/tech/full_papers/Ghodsi.pdf . Primary definition and theoretical model. Apache Hadoop, DominantResourceCalculator: https://hadoop.apache.org/docs/current2/hadoop-yarn/hadoop-yarn-common/apidocs/org/apache/hadoop/yarn/util/resource/DominantResourceCalculator.html . Primary implementation documentation; relevant indexed description reviewed. Wang, Li and Liang, Dominant Resource Fairness in Cloud Computing Systems with Heterogeneous Servers: https://arxiv.org/abs/1308.0083 . Primary research abstract illustrating why heterogeneous placement needs extensions.

Previous: Dominance-based rough set approach Next: Dominant strategy