New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve performance of NodeResourcesFit scoring #114121
Comments
@alculquicondor: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/sig scheduling |
have you considered sync.Pool? https://pkg.go.dev/sync#example-Pool |
That sounds like more overhead than a simple slice. These are all sync operations. |
Hi, @alculquicondor If I understand correctly, |
yes, that's roughly the plan. There will be a lot of trial-and-error. |
/assign |
/assign |
@ruquanzhao I've already started. Do you want to continue? |
/unassign @Zhaoruquan This was already assigned. |
/unassign @ruquanzhao |
If I understand correctly, I need to add a test function like
|
I suggest you first add the benchmark. Then, try to replace the maps with slices. Probably both |
Thanks. |
What would you like to be added?
Profiling reveals that a non-negligible amount of time is wasted creating and querying small maps (example:
make(resourceToValueMap)
, with an expected size of 2 or 3). I believe we should be able to replace them with slices for a performance boost.We should build unit-level benchmarks to proof that the improvements are good, similar to
kubernetes/pkg/scheduler/framework/plugins/podtopologyspread/scoring_test.go
Line 1272 in 8f2371b
Why is this needed?
While the plugin has decent performance, if we try to push the limits of kube-scheduler, there's still room for improvement.
The text was updated successfully, but these errors were encountered: