Context: reducing the cost and V(4) log volume of fair-sharing preemption. Companion to #14348, which collapses the per-candidate Evaluating FairSharing strategy log; this removes the work entirely for the provably-unsatisfiable case.
What happens
runFirstFsStrategy evaluates the tournament per candidate workload: for each candidate ClusterQueue it computes shares, and for each of that CQ's workloads it calls ComputeTargetShareAfterRemoval (which walks the resource tree to the cohort root) and runs the strategy (preemption.go#L397-L451).
When the preemptor's DominantResourceShare is +Inf, no candidate can pass. A DRS is +Inf only when a node borrows while its fair weight is 0 (the API defines a zero weight as an infinite share, and a non-zero weight is validated > 1e-9, fair_sharing.go#L93-L96). CompareDRS ranks such a preemptor above every target that is not itself a zero-weight borrower and returns 1 (fair_sharing.go#L112-L119), so both default strategies (LessThanOrEqualToFinalShare, LessThanInitialShare) reject every candidate. The tournament evaluates every candidate, all fail, then runSecondFsStrategy iterates them again.
Why it matters
This is O(candidate workloads) per such preemption attempt, each evaluation walking to the cohort root, on the scheduling dry-run path. findCandidates collects preemptible workloads across the whole root cohort (preemption.go#L594), so on a saturated cluster a single such preemptor can enumerate on the order of a thousand candidate workloads spread across dozens of ClusterQueues, all provably rejected, every cycle. It is also the dominant source of the Evaluating FairSharing strategy log at V(4).
Fix
Before the per-candidate loop, detect the case (preemptor share +Inf, target share not) and skip the loop for that ClusterQueue. Drain its candidates into retryCandidates so rule S2-b still runs on a snapshot the loop may have changed, rather than DropQueue. The zero-vs-zero case (target also +Inf) must not be skipped: CompareDRS falls back to the raw ratio there and preemption can still pass.
PR to follow.
Context: reducing the cost and V(4) log volume of fair-sharing preemption. Companion to #14348, which collapses the per-candidate
Evaluating FairSharing strategylog; this removes the work entirely for the provably-unsatisfiable case.What happens
runFirstFsStrategyevaluates the tournament per candidate workload: for each candidate ClusterQueue it computes shares, and for each of that CQ's workloads it callsComputeTargetShareAfterRemoval(which walks the resource tree to the cohort root) and runs the strategy (preemption.go#L397-L451).When the preemptor's DominantResourceShare is
+Inf, no candidate can pass. A DRS is+Infonly when a node borrows while its fair weight is 0 (the API defines a zero weight as an infinite share, and a non-zero weight is validated> 1e-9, fair_sharing.go#L93-L96).CompareDRSranks such a preemptor above every target that is not itself a zero-weight borrower and returns 1 (fair_sharing.go#L112-L119), so both default strategies (LessThanOrEqualToFinalShare,LessThanInitialShare) reject every candidate. The tournament evaluates every candidate, all fail, thenrunSecondFsStrategyiterates them again.Why it matters
This is
O(candidate workloads)per such preemption attempt, each evaluation walking to the cohort root, on the scheduling dry-run path.findCandidatescollects preemptible workloads across the whole root cohort (preemption.go#L594), so on a saturated cluster a single such preemptor can enumerate on the order of a thousand candidate workloads spread across dozens of ClusterQueues, all provably rejected, every cycle. It is also the dominant source of theEvaluating FairSharing strategylog at V(4).Fix
Before the per-candidate loop, detect the case (preemptor share
+Inf, target share not) and skip the loop for that ClusterQueue. Drain its candidates intoretryCandidatesso rule S2-b still runs on a snapshot the loop may have changed, rather thanDropQueue. The zero-vs-zero case (target also+Inf) must not be skipped:CompareDRSfalls back to the raw ratio there and preemption can still pass.PR to follow.