Skip to content
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

Reasonableness of resource estimates #2234

Open
LY-today opened this issue Oct 24, 2024 · 1 comment
Open

Reasonableness of resource estimates #2234

LY-today opened this issue Oct 24, 2024 · 1 comment
Labels
area/koord-scheduler kind/proposal Create a report to help us improve

Comments

@LY-today
Copy link
Contributor

LY-today commented Oct 24, 2024

When the func of estimatedUsedByResource estimates the resource usage of the Pod, if the pod's request is less than the limit, then use the limit as the estimated value. If the request is equal to the limit, then use the limit * scalingFactor (scalingFactor is a preset value, the default In this case, the scalingFactor of the CPU is 85%) as an estimate. According to the QoS category and corresponding operation quality requirements, shouldn't the larger the estimate in the Guaranteed case, and the buffer estimate in the Burstable case, the higher the stability of the final scheduling result? But looking at the implementation, it seems to be exactly the opposite. I haven’t seen any design and implementation documentation for this in the community.

@LY-today LY-today added the kind/proposal Create a report to help us improve label Oct 24, 2024
@LY-today LY-today changed the title [proposal] Reasonableness of resource estimates Oct 24, 2024
@saintube
Copy link
Member

Duplicated #2232.
Will be fixed by #2242.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/koord-scheduler kind/proposal Create a report to help us improve
Projects
None yet
Development

No branches or pull requests

2 participants