-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[ws-daemon] Fix cgroups v2 I/O limiting and add support for Systemd cgroup #10669
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
f8466c5
to
ae601b4
Compare
/werft run 👍 started the job as gitpod-build-aledbf-fuse.7 |
8082c15
to
cb89c5b
Compare
ca63271
to
9062a35
Compare
started the job as gitpod-build-aledbf-fuse.26 because the annotations in the pull request description changed |
started the job as gitpod-build-aledbf-fuse.27 because the annotations in the pull request description changed |
started the job as gitpod-build-aledbf-fuse.28 because the annotations in the pull request description changed |
started the job as gitpod-build-aledbf-fuse.29 because the annotations in the pull request description changed |
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.
Code looks great - how I can test?
You can use https://github.com/gitpod-io/workspace-preview/pull/44 to start a workspace preview (cgroups v2 is already enabled) |
} | ||
|
||
return setup == Legacy, nil | ||
return cgroups.Mode() == cgroups.Unified, nil |
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.
We have discussed using containerd or runc cgroup libs, and we decided not to depend on any libs. WDYT?
#8471 (comment)
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.
We already have that library as a dependency. Not sure that argument is valid?
I tried it in a cgroup v2 environment. However, only one eBPF code was found. The contents were probably runc defaults, and not even the fuse plugin was working. Am I looking in the wrong path? root@g024e48b9450d35ffc790c7:/# bpftool cgroup tree /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod87551354_d6d6_458c_8c02_23ec6701dea7.slice/cri-containerd-d9cf7e0f5eee155572588b05ffa9a1a13d2a0ee1c53660f35cc2ee5dfb57a6c7.scope
CgroupPath
ID AttachType AttachFlags Name
/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod87551354_d6d6_458c_8c02_23ec6701dea7.slice/cri-containerd-d9cf7e0f5eee155572588b05ffa9a1a13d2a0ee1c53660f35cc2ee5dfb57a6c7.scope
612 device multi root@g024e48b9450d35ffc790c7:/# bpftool prog dump xlat id 612
0: (61) r2 = *(u32 *)(r1 +0)
1: (54) w2 &= 65535
2: (61) r3 = *(u32 *)(r1 +0)
3: (74) w3 >>= 16
4: (61) r4 = *(u32 *)(r1 +4)
5: (61) r5 = *(u32 *)(r1 +8)
6: (55) if r2 != 0x1 goto pc+5
7: (bc) w1 = w3
8: (54) w1 &= 1
9: (5d) if r1 != r3 goto pc+2
10: (b4) w0 = 1
11: (95) exit
12: (55) if r2 != 0x2 goto pc+5
13: (bc) w1 = w3
14: (54) w1 &= 1
15: (5d) if r1 != r3 goto pc+2
16: (b4) w0 = 1
17: (95) exit
18: (55) if r2 != 0x2 goto pc+4
19: (55) if r4 != 0x1 goto pc+3
20: (55) if r5 != 0x3 goto pc+2
21: (b4) w0 = 1
22: (95) exit
23: (55) if r2 != 0x2 goto pc+4
24: (55) if r4 != 0x1 goto pc+3
25: (55) if r5 != 0x5 goto pc+2
26: (b4) w0 = 1
27: (95) exit
28: (55) if r2 != 0x2 goto pc+4
29: (55) if r4 != 0x1 goto pc+3
30: (55) if r5 != 0x7 goto pc+2
31: (b4) w0 = 1
32: (95) exit
33: (55) if r2 != 0x2 goto pc+4
34: (55) if r4 != 0x1 goto pc+3
35: (55) if r5 != 0x8 goto pc+2
36: (b4) w0 = 1
37: (95) exit
38: (55) if r2 != 0x2 goto pc+4
39: (55) if r4 != 0x1 goto pc+3
40: (55) if r5 != 0x9 goto pc+2
41: (b4) w0 = 1
42: (95) exit
43: (55) if r2 != 0x2 goto pc+4
44: (55) if r4 != 0x5 goto pc+3
45: (55) if r5 != 0x0 goto pc+2
46: (b4) w0 = 1
47: (95) exit
48: (55) if r2 != 0x2 goto pc+4
49: (55) if r4 != 0x5 goto pc+3
50: (55) if r5 != 0x2 goto pc+2
51: (b4) w0 = 1
52: (95) exit
53: (55) if r2 != 0x2 goto pc+4
54: (55) if r4 != 0xa goto pc+3
55: (55) if r5 != 0xc8 goto pc+2
56: (b4) w0 = 1
57: (95) exit
58: (55) if r2 != 0x2 goto pc+3
59: (55) if r4 != 0x88 goto pc+2
60: (b4) w0 = 1
61: (95) exit
62: (b4) w0 = 0
63: (95) exit This code, for example, the following section can be interpreted this way. And
The test for this fuse device fails. However, fuse may have nothing to do with this PR. #define _GNU_SOURCE
include <unistd.h>.
#include <sys/syscall.h> (syscall)
#include <linux/fs.h>.
#include <sys/types.h>.
#include <sys/stat.h>
#include <fcntl.h> (English)
#include <stdio.h> (English)
int main() {
const char* src_path = "/dev/fuse";
unsigned int flags = O_RDWR;
printf("RET: %ld", syscall(SYS_openat, AT_FDCWD, src_path, flags))
} In summary, I have two questions.
Here is "cpulimit": {
"enabled": true,
"totalBandwidth": "12",
"limit": "2",
"burstLimit": "4",
"controlPeriod": "15s",
"cgroupBasePath": "/mnt/node-cgroups"
},
"ioLimit": {
"writeBandwidthPerSecond": "300Mi",
"readBandwidthPerSecond": "350Mi",
"writeIOPS": 0,
"readI |
@utam0k fuse is working correctly now. Please review again. |
I checked. It works fine!!!
|
|
||
ioMaxFile := filepath.Join(basePath, cgroupPath) | ||
_, err := v2.NewManager(basePath, filepath.Join("/", cgroupPath), c.limits) |
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.
We only want to write the value to io.max
, right? Why do you use contained Manager?
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 was a little difficult to know what this code means because I had to assume some kinds of things.
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.
I actually mistakenly thought this was updating the device filter and changing the eBPF. However, I admit I was a little dumb.
The behavior itself is the charm. Thank you @aledbf |
Can confirm @utam0k's findings.Looks good to me. |
Release Notes