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

config-linux: add idle option for container cgroup #1136

Merged
merged 2 commits into from Apr 20, 2022

Conversation

wineway
Copy link
Contributor

@wineway wineway commented Feb 16, 2022

sched: Cgroup SCHED_IDLE support is introduced in Linux 5.15

we can mark a container SCHED_IDLE with this feature which means its sched weight are configured to the minimum

see also #1135

Signed-off-by: wineway <wangyuweihx@gmail.com>
Copy link
Member

@giuseppe giuseppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dqminh
Copy link
Contributor

dqminh commented Feb 16, 2022

LGTM

@tianon
Copy link
Member

tianon commented Feb 17, 2022

Looking at torvalds/linux@3040003, I think this was even in 5.15. 😅

@@ -361,6 +361,7 @@ The following parameters can be specified to set up the controller:
* **`realtimePeriod`** *(uint64, OPTIONAL)* - same as **`period`** but applies to realtime scheduler only
* **`cpus`** *(string, OPTIONAL)* - list of CPUs the container will run in
* **`mems`** *(string, OPTIONAL)* - list of Memory Nodes the container will run in
* **`idle`** *(int64, OPTIONAL)* - cgroups are configured with minimum weight, 0: default behavior, 1: SCHED_IDLE.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm getting mixed signals on the actual "type" of this value from torvalds/linux@3040003#diff-1b49efb1a709264f46f4ac518b965e9620acc2f5b928209547313b8dfc9f1286R400 (int) vs torvalds/linux@3040003#diff-1b49efb1a709264f46f4ac518b965e9620acc2f5b928209547313b8dfc9f1286R511 (long) -- it doesn't make a huge difference since the only values are 0 and 1, but I think any future changes/improvements will benefit if we match the kernel's type size from the get go. 😅

Any ideas which one is "canonical" ? (unfortunately I'm not very familiar with the kernel source to be able to parse this diff better than the two conflicting lines I found 🙈)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doest it support magic values like -1 ? (wondering if it would make it easier to use to use an uintXX if it only supports 0 and 1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text around it implies that it might someday? It does not currently. Currently it supports 0 and 1. What I'd like to do is make sure the type we choose matches the type the kernel uses, but I guess int64 fits both of C's int and long on all platforms I'm aware of, so I guess it should be plenty. 👍

@@ -361,6 +361,7 @@ The following parameters can be specified to set up the controller:
* **`realtimePeriod`** *(uint64, OPTIONAL)* - same as **`period`** but applies to realtime scheduler only
* **`cpus`** *(string, OPTIONAL)* - list of CPUs the container will run in
* **`mems`** *(string, OPTIONAL)* - list of Memory Nodes the container will run in
* **`idle`** *(int64, OPTIONAL)* - cgroups are configured with minimum weight, 0: default behavior, 1: SCHED_IDLE.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doest it support magic values like -1 ? (wondering if it would make it easier to use to use an uintXX if it only supports 0 and 1

@@ -330,6 +330,8 @@ type LinuxCPU struct {
Cpus string `json:"cpus,omitempty"`
// List of memory nodes in the cpuset. Default is to use any available memory node.
Mems string `json:"mems,omitempty"`
// cgroups are configured with minimum weight, 0: default behavior, 1: SCHED_IDLE. Default 0
Idle *int64 `json:"idle,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want const / enums for these values (for easier consumption)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, if 0 is the default behavior, it may not be needed to define it as a pointer

@wineway
Copy link
Contributor Author

wineway commented Feb 18, 2022

Looking at torvalds/linux@3040003, I think this was even in 5.15. 😅

@tianon yes, updated issue & pr comment.

@wineway wineway requested a review from tianon February 18, 2022 05:18
Signed-off-by: wineway <wangyuweihx@gmail.com>
@@ -361,6 +361,7 @@ The following parameters can be specified to set up the controller:
* **`realtimePeriod`** *(uint64, OPTIONAL)* - same as **`period`** but applies to realtime scheduler only
* **`cpus`** *(string, OPTIONAL)* - list of CPUs the container will run in
* **`mems`** *(string, OPTIONAL)* - list of Memory Nodes the container will run in
* **`idle`** *(int64, OPTIONAL)* - cgroups are configured with minimum weight, 0: default behavior, 1: SCHED_IDLE.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text around it implies that it might someday? It does not currently. Currently it supports 0 and 1. What I'd like to do is make sure the type we choose matches the type the kernel uses, but I guess int64 fits both of C's int and long on all platforms I'm aware of, so I guess it should be plenty. 👍

@vbatts vbatts merged commit e54040a into opencontainers:main Apr 20, 2022
@giuseppe
Copy link
Member

the PR doesn't update the json schema, opened another one: #1145

flouthoc added a commit to flouthoc/libocispec that referenced this pull request Aug 26, 2022
See: opencontainers/runtime-spec#1136

Signed-off-by: Aditya R <arajan@redhat.com>
flouthoc added a commit to flouthoc/libocispec that referenced this pull request Aug 26, 2022
See: opencontainers/runtime-spec#1136

Signed-off-by: Aditya R <arajan@redhat.com>
@AkihiroSuda AkihiroSuda mentioned this pull request Jan 24, 2023
@AkihiroSuda AkihiroSuda added this to the v1.1.0 milestone Feb 1, 2023
@AkihiroSuda AkihiroSuda mentioned this pull request Jun 26, 2023
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants