-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
When runc updates the values of cpu-rt-period and cpu-rt-runtime synchronously, an error occurs. #4094
Comments
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 1, 2024
…untime_us As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. Sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us (called period_new), the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first, new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 1, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first. new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 1, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first. new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 1, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first. new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 1, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first. new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 1, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first. new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 2, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first. new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 2, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first so that the new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 12, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first so that the new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 14, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first so that the new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 14, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first so that the new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
ls-ggg
added a commit
to ls-ggg/runc
that referenced
this issue
Apr 28, 2024
As reported in issue opencontainers#4094, sometimes setting rt_period_us and rt_runtime_us at the same time will fail. The reason is that in cgroupv1, these two values cannot be set atomically. When we set a new rt_period_us, the kernel will determine whether the current configuration of new_limit1 = old_quota/new_period exceeds the limit. If it exceeds the limit, an error will be reported. Maybe it is reasonable to set rt_runtime_us first so that the new_limit2 = new_quota/old_period. for example: The original state of cgv1 is rt_period_us: 10000 rt_runtime_us: 5000 The user wants to change it to rt_period_us: 1000 rt_runtime_us:300. The new rt_runtime_us should be set first. In the opposite case, if rt_runtime_us is set first, new_limit2 may still exceed the limit, but new_limit1 will be valid. for example: The original state of cgv1 is rt_period_us: 1000 rt_runtime_us: 500 The user wants to change it to rt_period_us: 10000 rt_runtime_us:3000. The new rt_period_us should be set first. Therefore, new_limit1 and new_limit2 should be calculated in advance, and the smaller corresponding setting order should be selected to set rt_period_us and rt_runtime_us. Signed-off-by: ls-ggg <[email protected]>
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
For example:
(1)when creating a container, set the parameters to: --cpu-rt-runtime 950000 --cpu-rt-period 1000000.
(2)If the update parameters are --cpu-rt-runtime 5000 --cpu-rt-period 960000, runc cannot successfully updated。It will report an error: Invalid parameter
The reason is that in the SetRtSched function of runc, the cpu-rt-period value is written first and then the cpu-rt-runtime value. If the cpu-rt-period value is written without complying with the cgroup rules, an error will be reported and returned directly.
Describe the results you received and expected
runc successfully updated
What version of runc are you using?
runc version 1.1.3
commit: v1.1.3-0-g6724737f-dirty
spec: 1.0.2-dev
go: go1.20.8
libseccomp: 2.5.1
The text was updated successfully, but these errors were encountered: