Add cgroup v2 support to .NET Core

[omajid]

The Linux kernel includes a feature called "cgroup" (or "cgroups"). This allows managing - specially limiting - resources (cpu, memory, etc) for a collection of processes. This is one of the underlying technology pieces used by projects like docker, podman, kubernetes and systemd to limit various resources for processes.

The first version of cgroup has a number of design issues and a redesign, cgroup v2, was implemented in the Linux kernel. There are a number of incompatibilities between cgroup v1 and cgroup v2.

Complete documentation of cgroup v2 is available here: https://www.kernel.org/doc/Documentation/cgroup-v2.txt

Both cgroup v1 and cgroup v2 may be enabled on a system at the same time. Container runtimes (podman, docker) will only use one.

Some Linux distributions, such as Fedora, are starting to switch to cgroup v2 as the default: https://fedoraproject.org/wiki/Changes/CGroupsV2. Even where it's not the default, adding systemd.unified-cgroup-hierarchy=1 to the kernel command can be used to make it the default for testing.

A technique to disambiguate between cgroup v1 and cgroup v2 is documented here: https://systemd.io/CGROUP_DELEGATION/#three-different-tree-setups-

Currently, .NET Core doesn't support cgroup v2. This issue is for tracking the changes/fixes required across the different .NET Components.

CoreCLR:

• Add cgroup v2 support to PAL's cgroup.cpp and gc's cgroup.cpp: Add cgroup v2 support to coreclr #34334 (originally Add cgroup v2 support to CoreCLR coreclr#25906, but not merged due to repo move)

CoreFx:

• Fix reading the memory limit in Interop.cgroups.cs: Add cgroup v2 support to Interop.cgroups corefx#39686
• Fix cgroup2fs in the file system information in Interop.MountPoints.FormatInfo.cs: Fix up cgroup2fs in Interop.MountPoints.FormatInfo corefx#39633
• Sync cgroup v2 implementation in corefx with that in coreclr: Sync cgroup v2 in libraries with coreclr #34665

[carlossanlop]

Thank you for the details, @omajid and for fixing issue dotnet/corefx#39633. Based on this, I will move this issue to the corefx repo, for better tracking and higher visibility.

[Maoni0]

@janvorli would you please take a look at cgroup2 and see if it's a simple matter of adopting it (eg, read the same values just from different places kind of thing) or does it mean we'll need to handle new scenarios enabled by cgroup2 and/or does it make us change anything we are currently doing?

[omajid]

@carlossanlop Thanks for raising the visibility of this issue. I was hoping to use this bug as a tracker and track fixes across multiple components, not just corefx. Is there a better place to file such bugs that have a larger scope?

[omajid]

Oh, and in case it was not obvious, I am planning (hoping?) on contributing all the required fixes to corefx and coreclr (and anything else that pops up).

[carlossanlop]

Bugs, feature requests, proposals need to all be opened in dotnet/corefx. That is my understanding. Everything happens here. @danmosemsft would you mind confirming if this is the right answer?

The dotnet/core repo is used mainly as a central point for people using our tutorials to report issues, so it has very little visibility and activity.

[danmoseley]

Bugs, feature requests, proposals need to all be opened in dotnet/corefx. That is my understanding. Everything happens here. @danmosemsft would you mind confirming if this is the right answer?

Yup, we track work in corefx with issues in corefx repo.

[danmoseley]

cc @richlander

[omajid]

I am going to close this issue now that all my initial patches have been merged into master branches.

Any further changes (features or bugfixes) should probably be handled separately.

[omajid]

Could someone please update the tags on this? I think this could be classified as enhancement and os-linux?