[
https://issues.apache.org/jira/browse/YUNIKORN-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hedger Lai updated YUNIKORN-3463:
---------------------------------
Description:
h3. Symptom
In {{Preemptor.calculateAdditionalVictims()}}, if an early candidate victim
cannot fit into the ask queue's remaining guaranteed headroom, the loop
executes a raw {{break}}. Because potential victims are sorted by score and
creation time rather than resource size, an oversized candidate prematurely
aborts the search, starving subsequent viable smaller victims across the queue
tree and causing preemption to fail unnecessarily.
h3. Root Cause
In {{pkg/scheduler/objects/preemption.go}} around line 514:
{code:go}
askQueueRemaining := askQueue.GetRemainingGuaranteedResource()
if askQueueRemaining != nil &&
askQueueRemaining.FitInActual(victim.GetAllocatedResource()) {
askQueue.AddAllocation(victim.GetAllocatedResource())
} else {
queueSnapshot.AddAllocation(victim.GetAllocatedResource())
break // <-- premature abort on oversized candidate
}
{code}
h3. Proposed Fix
Replace {{break}} with {{continue}} in the {{else}} branch so subsequent viable
candidates can be evaluated. Downstream in {{TryPreemption()}}, extra victims
are already properly pruned and capped to the ask's exact resource demand.
was:
h3. Symptom
In {{Preemptor.calculateAdditionalVictims()}}, preemption for queue quota
exhibits two loop control defects:
1. If an early candidate victim cannot fit in the ask queue's remaining
guaranteed headroom, the loop executes a raw {{break}}, prematurely aborting
the search and starving subsequent viable victims.
2. Conversely, when accumulated victims have already satisfied the ask queue's
guaranteed quota, the loop fails to exit early, scanning remaining victims
unnecessarily.
h3. Root Cause
In {{pkg/scheduler/objects/preemption.go}}:
{code:go}
askQueueRemaining := askQueue.GetRemainingGuaranteedResource()
if askQueueRemaining != nil &&
askQueueRemaining.FitInActual(victim.GetAllocatedResource()) {
askQueue.AddAllocation(victim.GetAllocatedResource())
} else {
queueSnapshot.AddAllocation(victim.GetAllocatedResource())
break // <-- Flaw 1: premature abort on fit failure
}
// ...
// Flaw 2: missing early-stop when quota is already satisfied
{code}
h3. Proposed Fix
1. In the {{else}} branch of {{FitInActual()}}, replace {{break}} with
{{continue}} to evaluate subsequent viable candidates.
2. After appending a valid victim, {{break}} immediately if
{{isAskQueueUnderGuaranteed()}} is satisfied.
> [Core] Premature loop abort in calculateAdditionalVictims starves preemption
> ----------------------------------------------------------------------------
>
> Key: YUNIKORN-3463
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3463
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: core - scheduler
> Reporter: Hedger Lai
> Assignee: Hedger Lai
> Priority: Major
> Fix For: 1.6.0
>
>
> h3. Symptom
> In {{Preemptor.calculateAdditionalVictims()}}, if an early candidate victim
> cannot fit into the ask queue's remaining guaranteed headroom, the loop
> executes a raw {{break}}. Because potential victims are sorted by score and
> creation time rather than resource size, an oversized candidate prematurely
> aborts the search, starving subsequent viable smaller victims across the
> queue tree and causing preemption to fail unnecessarily.
> h3. Root Cause
> In {{pkg/scheduler/objects/preemption.go}} around line 514:
> {code:go}
> askQueueRemaining := askQueue.GetRemainingGuaranteedResource()
> if askQueueRemaining != nil &&
> askQueueRemaining.FitInActual(victim.GetAllocatedResource()) {
> askQueue.AddAllocation(victim.GetAllocatedResource())
> } else {
> queueSnapshot.AddAllocation(victim.GetAllocatedResource())
> break // <-- premature abort on oversized candidate
> }
> {code}
> h3. Proposed Fix
> Replace {{break}} with {{continue}} in the {{else}} branch so subsequent
> viable candidates can be evaluated. Downstream in {{TryPreemption()}}, extra
> victims are already properly pruned and capped to the ask's exact resource
> demand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
