manirajv06 commented on code in PR #1035:
URL: https://github.com/apache/yunikorn-core/pull/1035#discussion_r2454520488
##########
pkg/scheduler/objects/application.go:
##########
@@ -1364,14 +1362,22 @@ func (sa *Application) tryReservedAllocate(headRoom
*resources.Resource, nodeIte
return nil
}
-func (sa *Application) tryPreemption(headRoom *resources.Resource,
preemptionDelay time.Duration, ask *Allocation, iterator NodeIterator,
nodesTried bool) (*AllocationResult, bool) {
+func (sa *Application) tryPreemption(headRoom *resources.Resource,
preemptionDelay time.Duration, preemptionAttemptsRemaining *int, ask
*Allocation, iterator NodeIterator, nodesTried bool) (*AllocationResult, bool) {
+ if *preemptionAttemptsRemaining == 0 {
+ log.Log(log.SchedApplication).Debug("Max queue preemption
attempts exhausted",
+ zap.String("allocationKey", ask.GetAllocationKey()),
+ zap.String("applicationID", sa.ApplicationID),
+ zap.String("queue", sa.queuePath))
+ return nil, false
+ }
preemptor := NewPreemptor(sa, headRoom, preemptionDelay, ask, iterator,
nodesTried)
// validate prerequisites for preemption of an ask and mark ask for
preemption if successful
if !preemptor.CheckPreconditions() {
ask.LogAllocationFailure(common.PreemptionPreconditionsFailed,
true)
return nil, false
}
+ *preemptionAttemptsRemaining--
Review Comment:
No, that doesn't make sense. Whole purpose of having max counter to control
the no. of preemption process per cycle for the given queue itself would be
lost if we start doing that way. With this change, we don't take precondition
failures into account and start decrementing the counter when actual preemption
process starts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
