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

Proposal: add Core Scheduling support #1113

Open
kailun-qin opened this issue Aug 4, 2021 · 2 comments
Open

Proposal: add Core Scheduling support #1113

kailun-qin opened this issue Aug 4, 2021 · 2 comments

Comments

@kailun-qin
Copy link
Contributor

Linux 5.14 adds the support for Core Scheduling.

Core scheduling support allows userspace to define groups of tasks that can share a core. These groups can be specified either for security usecases (one group of tasks don’t trust another), or for performance usecases (some workloads may benefit from running on the same core as they don’t need the same hardware resources of the shared core, or may prefer different cores if they do share hardware resource needs). This is achieved by setting and copying core scheduling task cookies between the threads (PID), processes (TGID), and process groups (PGID). See the kernel doc for further details.

This would be useful for all containers within a pod. Also, it is particularly helpful for multi-tenant environments.

runc requirement: opencontainers/runc#3061.

kailun-qin added a commit to kailun-qin/runtime-spec that referenced this issue Aug 4, 2021
Linux kernel 5.14 adds the support for Core Scheduling.

This allows setting and copying core scheduling 'task cookies' between
the container process and the threads (PID), processes (TGID), and
process groups (PGID), which helps define groups of tasks that can be
co-scheduled on the same core. These groups can be specified either for
security usecases or for performance usecases.

opencontainers#1113

Signed-off-by: Kailun Qin <[email protected]>
@sfc-gh-hyu
Copy link

Is there any update on this proposal? What's blocking this from moving forward?

@kailun-qin
Copy link
Contributor Author

Is there any update on this proposal? What's blocking this from moving forward?

Thanks for the interest! Let's try to move the spec review forward.

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

No branches or pull requests

2 participants