[YUNIKORN-3113] Resource-wise preemption #1029
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1029 +/- ##
==========================================
+ Coverage 81.85% 81.90% +0.04%
==========================================
Files 103 103
Lines 13608 13652 +44
==========================================
+ Hits 11139 11181 +42
- Misses 2208 2210 +2
Partials 261 261 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| return false | ||
| } | ||
|
|
||
| oldRemaining := currentQueue.GetRemainingGuaranteedResource() |
There was a problem hiding this comment.
We can directly return here if the ask fits in the oldRemaining.
if oldRemaining.FitInMaxUndef(ask) {
retrun true
}
examples:
oldRemaining 5 cpu, -10 GPU -100 memory
- ask 1 cpu -> pass
- ask 1 cpu, 1 GPU -> fail
- ask 1 cpu, 1 storage -> pass
| // If both resources are nil, return nil resource | ||
| // If no resource type matches, return nil resource | ||
| // If resource type exists and none modified, return nil resource | ||
| func ExtractLatestIfModified(old *Resource, new *Resource) *Resource { |
There was a problem hiding this comment.
This is so specific to just the preemption it would be better to add it in the preemption code
pkg/scheduler/objects/preemption.go
Outdated
| // the removal of victim on ask queue. In case of res type not used in victim but defined in ask queue's guaranteed, | ||
| // Net remaining value ensures it has only RELEVANT res types and not res types not being touched at all from victim context. | ||
| netRemaining := resources.ExtractLatestIfModified(oldRemaining, remaining) | ||
| if remaining != nil && resources.StrictlyGreaterThanOrEquals(netRemaining, resources.Zero) { |
There was a problem hiding this comment.
This breaks if a type changes but stays over guaranteed and that type is not requested by the ask:
- alloc 1 cpu, 2 GPU
- oldRemaining -1 cpu, -10 GPU -100 memory
- newRemaining 0 cpu, -8 GPU
in the pre-check we use a fitin setup we need to do something like it here just based on the types that are in the ask and ignore everything else
pkg/scheduler/objects/preemption.go
Outdated
| // Net remaining guaranteed is nothing but the latest remaining guaranteed value resulted after | ||
| // the removal of victim on ask queue. In case of res type not used in victim but defined in ask queue's guaranteed, | ||
| // Net remaining value ensures it has only RELEVANT res types and not res types not being touched at all from victim context. | ||
| askQueueNetRemaining := resources.ExtractLatestIfModified(askQueueOldRemaining, askQueueNewRemaining) |
There was a problem hiding this comment.
Same comment as above. ask and it types need to drive this check
…nto the ask queue or not instead of using strict based methods to avoid problems due to (from ask resource requirement perspective) unreleated res types with -ve values * Introduced two more methods in Preemptor to decide ask queue is under guaranteed and victim is over guranateed or not from ask resource requirement perspective. Used these methods in appropriate places to simplify the decision making * Added tests for the same.
manirajv06
force-pushed
the
YUNIKORN-3113
branch
from
202cb10 to
2457962
Compare
|
Introduced FitInActual() method to decide whether the ask would fit into the ask queue or not instead of using strict based methods to avoid problems due to (from ask resource requirement perspective) unrelated res types with -ve values. Introduced two more methods in Preemptor to decide ask queue is under guaranteed and victim is over guaranteed or not from ask resource requirement perspective. Replace the strict based in all appropriate places to simplify the decision making. Added tests for the same. |
2 participants
What is this PR for?
Increase the chances of preemption by looking at both the victim and ask queue left over (remaining) guaranteed resource from ask resource requirements perspective too, not only viewing it plainly. Victim queue with OG res types may have UG res types and Ask queue with UG res types may have OG res types. Trigger preemption during these situations when ask (preemptor) resource requirements starving for res types (supposed to get) but has nothing to do with UG res type in victim queue and OG res types in its own (ask) queue itself.
Introduced a Net remaining guaranteed resource variable to contain the latest value of modified resource type value for the given queue with potential victim eviction. This would help us in understanding the impact on guaranteed resources from victim eviction perspective. As long as relevant (impacted) res types is still above or equals guaranteed values, then it is good to ahead with actual preemption process.
What type of PR is it?
Todos
What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-3113
How should this be tested?
Screenshots (if appropriate)
Questions: