-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[ws-daemon] Fix CPU limit annotation #8459
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
Conversation
Codecov Report
@@ Coverage Diff @@
## main #8459 +/- ##
===========================================
+ Coverage 11.17% 32.42% +21.24%
===========================================
Files 18 92 +74
Lines 993 15074 +14081
===========================================
+ Hits 111 4887 +4776
- Misses 880 9794 +8914
- Partials 2 393 +391
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
/werft run with-vm 👍 started the job as gitpod-build-cw-fixlimit.1 |
457c3d4
to
4c931a4
Compare
@csweichel I cannot start a workspace. #8526 might fix it. |
I think it this PR, #8476 |
rebase to main is good option |
Hey @csweichel Is this PR in reviewable state? Thomas was not able to start the ws. There are also some conflicting changes |
Yeah, this has sat around for too long. It should be reviewable. Will rebase. |
The build is failing can you PTAL @csweichel |
Build fails because CgroupCFSController is now CgroupV1CFSController. |
Should it be rather |
I have pushed a commit with a fix |
retriggering a build as this one failed with a typescript code error. It might be intermittent. /werft run 👍 started the job as gitpod-build-cw-fixlimit.5 |
8b335dd
to
3cb57ed
Compare
I tried it and could observe that the cpu quota was set to the annotation value. |
|
||
// if we didn't get the max bandwidth, but were throttled last time | ||
// and there's still some bandwidth left to give, let's act as if had | ||
// never spent any CPU time and assume the workspace will spend their | ||
// entire bandwidth at once. | ||
var burst bool | ||
if totalBandwidth < d.TotalBandwidth && ws.Throttled() { | ||
limit = d.BurstLimiter.Limit(ws.Usage()) | ||
limiter := d.BurstLimiter | ||
if w := wsidx[id]; w.BaseLimit > 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this check for w.BurstLimiter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It totally should. This basically means that a workspace with a base limit (i.e. cpuLimit
annotation) will only ever get that limit, and will never burst.
In practice that has no effect though because we set the base and burst limit to the same value when that annotation is applied.
Description
When we updated the CPU limiting mechanism, we broke the
gitpod.io/cpuLimit
annotation. This PR makes that annotation work again. It effectively controls the base and burst limits of a workspace.How to test
gitpod.io/cpuLimit
annotation on that workspaceRelease Notes