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

cgroup v2 support #94

Closed
Ferroin opened this issue Aug 16, 2016 · 4 comments
Closed

cgroup v2 support #94

Ferroin opened this issue Aug 16, 2016 · 4 comments

Comments

@Ferroin
Copy link
Contributor

Ferroin commented Aug 16, 2016

Version 2 of cgroups has been considered stable in the mainline kernel for two release cycles now. It would be really nice to have the option to use it with OpenRC.

Based on my (limited) knowledge of the internals of cgroupv2 and OpenRC, here's what would have to change:

  • Add an option in rc.conf to select between cgroup v1 and cgroup v2 support.
  • Abstract how paths are constructed to files in cgroups. cgroup v2 uses a unified hierarchy (equivalent to everything being co-mounted), usually rooted at /sys/fs/cgroup.
  • Add a config option to select which controllers to enable when using cgroup v2. cgroup v2 requires controllers to be explicitly enabled before they can be used.
  • Add a config option to specify parameters for cgroup v2 controllers. Because of the unified hierarchy, it makes little sense to split the config for each controller to a separate variable.
@williamh
Copy link
Contributor

Yes, I am interested in supporting this, and will start working on it soon.

@stalkerg
Copy link

Can you say about current status?

@williamh
Copy link
Contributor

williamh commented Sep 3, 2017

Cgroups v2 wasn't actually considered stable upstream until linux-4.13 which has just been released today, so I will begin working on it.

Does anyone have any suggestions about whether I should keep cgroups v1 around and how to do that?The cgroups v1 code is buggy due to race conditions which I haven't been able to reproduce, much less solve, , so the sooner I could move completely away from cgroups v1 the better.

@Ferroin
Copy link
Contributor Author

Ferroin commented Sep 5, 2017

I would say you should absolutely keep cgroup v1 support around despite the bugs, there are things you can't do in cgroup v2 but can in cgroup v1 (they decided to ignore some of the primary use cases in designing cgroup v2, so there are a number of people who are or will be stuck on v1 for at least the foreseeable future).

From my perspective, I would think the cleanest way to do the cgroup v2 stuff from scratch, then use whatever variable is used to select v1 or v2 to select the implementation too. There might be some shareable code, but I don't think any of that reasonably shareable code is likely to be where the race conditions are.

williamh added a commit that referenced this issue Sep 14, 2017
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

3 participants