Skip to content
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

Open
zhongTao99 opened this issue Oct 25, 2023 · 0 comments · May be fixed by #4235 or #4258

Comments

@zhongTao99
Copy link

zhongTao99 commented Oct 25, 2023

Description

For example:

  1. When the updated cpu-rt-runtime value becomes smaller and the cpu-rt-period value also becomes smaller, the update is unsuccessful.
    (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.

func (s *CpuGroup) SetRtSched(path string, r *configs.Resources) error {
	if r.CpuRtPeriod != 0 {
		if err := cgroups.WriteFile(path, "cpu.rt_period_us", strconv.FormatUint(r.CpuRtPeriod, 10)); err != nil {
			return err
		}
	}
	if r.CpuRtRuntime != 0 {
		if err := cgroups.WriteFile(path, "cpu.rt_runtime_us", strconv.FormatInt(r.CpuRtRuntime, 10)); err != nil {
			return err
		}
	}
	return nil
}

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

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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
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 <335814617@qq.com>
@kolyshkin kolyshkin linked a pull request Apr 25, 2024 that will close this issue
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 <335814617@qq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant