You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction
to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do
not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Description
As proposed by @yyvess in #36 (comment) the container's CPU limits, if present, can be removed during the boost instead of being increased. This will allow to allocate even more CPU time if available. The behavior should be configuration driven with "always-on" default.
I am keen to understand the implications of the proposed change.
If the CPU resource limit is removed during a boost, could this potentially cause CPU resource contention/starvation for other applications running on the node, thereby impacting their stability and performance?
Thank you for your question. On a high level, when there is no CPU limit for a container, the container can use all of the resources available on a node. When multiple containers request for such excess (above the requests) CPU resources, the node's scheduler will try to distribute them (Linux uses CFS - completely fair scheduler - by default).
To sum up, only requested CPU resources are guaranteed. CPU resources that excess the requested ones are given on a best-effort only, distributed by the node's scheduler when available. Therefore, removing the CPU limits from a container is a safe operation and in most cases even a recommended practice.
Community Note
to the original issue to help the community and maintainers prioritize this request
not help prioritize the request
Description
As proposed by @yyvess in #36 (comment) the container's CPU limits, if present, can be removed during the boost instead of being increased. This will allow to allocate even more CPU time if available. The behavior should be configuration driven with "always-on" default.
References
The text was updated successfully, but these errors were encountered: