Add assignedNodeId field to JobSchedulingContext #3678
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes it far faster to look up the currently assigned node for a given evicted job - Currently it uses a map look up which is comparatively slow Signed-off-by: JamesMurkin <[email protected]>
Signed-off-by: JamesMurkin <[email protected]>
Signed-off-by: JamesMurkin <[email protected]>
Signed-off-by: JamesMurkin <[email protected]>
JamesMurkin
added a commit
that referenced
this pull request
Jun 17, 2024
Testing with the worst case, this makes the function 2-4 times faster - Combined with #3678 it is about 3-5 times faster Even the average case should be improved, as we now do less work The main "trick" here is to not perform node.UnsafeCopy() and nodeDb.unbindJobFromNodeInPlace until it is needed (once you know which node is the selected one) - These functions are expensive, particularly UnsafeCopy Instead just keep track of the evicted nodes + available resource locally until you've found one that matches. There are more enhancements that could be made here: - Work out when it is better to check static requirements first (possibly even save these and use them for all jobs with the same scheduling key) - Improve nodeDb speed to look up a node (use a map?) - Improve nodeDb speed to iterate evicted jobs (use a slice? / effectively we just need a sorted hashmap, not a fully fledged radix tree) Signed-off-by: JamesMurkin <[email protected]>
d80tb7
approved these changes
Jun 20, 2024
JamesMurkin
added a commit
that referenced
this pull request
Jun 21, 2024
* Improve performance of selectNodeForJobWithFairPreemption Testing with the worst case, this makes the function 2-4 times faster - Combined with #3678 it is about 3-5 times faster Even the average case should be improved, as we now do less work The main "trick" here is to not perform node.UnsafeCopy() and nodeDb.unbindJobFromNodeInPlace until it is needed (once you know which node is the selected one) - These functions are expensive, particularly UnsafeCopy Instead just keep track of the evicted nodes + available resource locally until you've found one that matches. There are more enhancements that could be made here: - Work out when it is better to check static requirements first (possibly even save these and use them for all jobs with the same scheduling key) - Improve nodeDb speed to look up a node (use a map?) - Improve nodeDb speed to iterate evicted jobs (use a slice? / effectively we just need a sorted hashmap, not a fully fledged radix tree) Signed-off-by: JamesMurkin <[email protected]> * Lint Signed-off-by: JamesMurkin <[email protected]> * Move struct definition inside function Signed-off-by: JamesMurkin <[email protected]> --------- Signed-off-by: JamesMurkin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes it far faster to look up the currently assigned node for a given evicted job