Skip to content

[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

Merged
merged 2 commits into from
Mar 16, 2022
Merged

[ws-daemon] Fix CPU limit annotation #8459

merged 2 commits into from
Mar 16, 2022

Conversation

csweichel
Copy link
Contributor

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

  1. Start a workspace
  2. Set the gitpod.io/cpuLimit annotation on that workspace
  3. Observe how the workspace's cfs quota gets set to that value

Release Notes

Made the `gitpod.io/cpuLimit` annotation work again

@csweichel csweichel requested a review from a team February 25, 2022 14:09
@github-actions github-actions bot added the team: workspace Issue belongs to the Workspace team label Feb 25, 2022
@csweichel csweichel marked this pull request as draft February 25, 2022 14:09
@codecov
Copy link

codecov bot commented Feb 25, 2022

Codecov Report

Merging #8459 (4c931a4) into main (37444f7) will increase coverage by 21.24%.
The diff coverage is 35.29%.

❗ Current head 4c931a4 differs from pull request most recent head 3cb57ed. Consider uploading reports for the commit 3cb57ed to get more accurate results

@@             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     
Flag Coverage Δ
components-gitpod-cli-app 11.17% <ø> (ø)
components-image-builder-mk3-app 35.71% <ø> (?)
components-supervisor-app 35.78% <ø> (?)
components-ws-daemon-app 20.17% <35.29%> (?)
components-ws-daemon-lib 20.17% <35.29%> (?)
components-ws-manager-app 39.29% <ø> (?)
components-ws-proxy-app 68.63% <ø> (?)
install-installer-raw-app 4.49% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
components/ws-daemon/pkg/cpulimit/dispatch.go 0.00% <0.00%> (ø)
components/ws-daemon/pkg/cpulimit/cpulimit.go 66.45% <46.15%> (ø)
...ents/image-builder-mk3/pkg/orchestrator/metrics.go 48.14% <0.00%> (ø)
components/supervisor/pkg/ports/ports.go 58.93% <0.00%> (ø)
components/ws-manager/pkg/manager/probe.go 0.00% <0.00%> (ø)
components/supervisor/pkg/ports/exposed-ports.go 0.00% <0.00%> (ø)
...onents/ws-daemon/pkg/internal/session/workspace.go 50.73% <0.00%> (ø)
components/ws-daemon/pkg/daemon/daemon.go 0.00% <0.00%> (ø)
...installer/pkg/components/ws-manager/rolebinding.go 0.00% <0.00%> (ø)
components/ws-proxy/pkg/proxy/workspacerouter.go 81.89% <0.00%> (ø)
... and 66 more

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

@csweichel
Copy link
Contributor Author

csweichel commented Feb 25, 2022

/werft run with-vm

👍 started the job as gitpod-build-cw-fixlimit.1

@Furisto
Copy link
Member

Furisto commented Mar 2, 2022

@csweichel I cannot start a workspace. #8526 might fix it.

@iQQBot
Copy link
Contributor

iQQBot commented Mar 2, 2022

I think it this PR, #8476

@iQQBot
Copy link
Contributor

iQQBot commented Mar 2, 2022

rebase to main is good option

@princerachit
Copy link
Contributor

Hey @csweichel Is this PR in reviewable state? Thomas was not able to start the ws. There are also some conflicting changes

@csweichel
Copy link
Contributor Author

Yeah, this has sat around for too long. It should be reviewable. Will rebase.

@princerachit
Copy link
Contributor

The build is failing can you PTAL @csweichel

@Furisto
Copy link
Member

Furisto commented Mar 14, 2022

Build fails because CgroupCFSController is now CgroupV1CFSController.

@princerachit
Copy link
Contributor

Build fails because CgroupCFSController is now CgroupV1CFSController.

Should it be rather CFSController in the code?

@princerachit
Copy link
Contributor

I have pushed a commit with a fix

@princerachit
Copy link
Contributor

princerachit commented Mar 16, 2022

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

@Furisto
Copy link
Member

Furisto commented Mar 16, 2022

I tried it and could observe that the cpu quota was set to the annotation value.

@roboquat roboquat merged commit ffe6f48 into main Mar 16, 2022
@roboquat roboquat deleted the cw/fixlimit branch March 16, 2022 12:06
@roboquat roboquat added deployed: workspace Workspace team change is running in production deployed Change is completely running in production labels Mar 16, 2022
@aledbf aledbf restored the cw/fixlimit branch April 18, 2022 19:12

// 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 {
Copy link
Contributor

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?

Copy link
Contributor Author

@csweichel csweichel Apr 19, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: workspace Workspace team change is running in production deployed Change is completely running in production release-note size/M team: workspace Issue belongs to the Workspace team
Projects
No open projects
Archived in project
Development

Successfully merging this pull request may close these issues.

6 participants