Skip to content

Determine any memory/CPU limitations from sysfs cgroup - #74237

Merged
akoeplinger merged 5 commits into
dotnet:mainfrom
nealef:mono_cgroup
Aug 31, 2022
Merged

Determine any memory/CPU limitations from sysfs cgroup#74237
akoeplinger merged 5 commits into
dotnet:mainfrom
nealef:mono_cgroup

Conversation

@nealef

Copy link
Copy Markdown
Contributor

Add capability to interrogate cgroup limitations when determining CP and memory limits

This code has been adapted from coreCLR. It has been modified from C++ but uses the same naming conventions in the event of a unified mechanism that can be shared between both runtimes being developed. The code has been tested on Ubuntu 20.04 and CentOS 7 with cgroupv1 and cgroupv2.

This code is required in the event of running runtime in a container as the current limitations being discovered by the mono runtime are purely for the machine and not in a container which may have lower quotas.

  • src/mono/CMakeLists.txt

    • Set the HAVE_CGROUP_SUPPORT for Linux hosts
  • src/mono/cmake/config.h.in

    • Place holder for HAVE_CGROU_SUPPORT definition
  • src/mono/mono/metadata/icall.c

  • src/mono/mono/sgen/sgen-marksweep.c

  • src/mono/mono/sgen/sgen-simple-nursery.c

    • Use mono_cpu_limit() instead of mono_cpu_count()
  • src/mono/mono/utils/CMakeLists.txt

    • Add mono-cgroup.c to the build
  • src/mono/mono/utils/memfuncs.c

    • Call getRestrictedPhysicalMemoryLimit() or getPhyscalMemoryAvail()
  • src/mono/mono/utils/memfuncs.h

    • Add prototypes for the new APIs
  • src/mono/mono/utils/mono-cgroup.c

    • Code adapted from coreCLR to interrogate sysfs to determine any limitations on memory or CPU
  • src/mono/mono/utils/mono-proclib.c

    • Add call to getCpuLimit()
  • src/mono/mono/utils/mono-proclib.h

    • Add prototype for the new API

Add capability to interrogate cgroup limitations when determining CP and memory limits
This code has been adapted from coreCLR. It has been modified from C++ but uses the same naming conventions in the event of a unified mechanism that can be shared between both runtimes being developed. The code has been tested on Ubuntu 20.04 and CentOS 7 with cgroupv1 and cgroupv2.
This code is required in the event of running runtime in a container as the current limitations being discovered by the mono runtime are purely for the machine and not in a container which may have lower quotas.
* src/mono/CMakeLists.txt
- Set the HAVE_CGROUP_SUPPORT for Linux hosts
* src/mono/cmake/config.h.in
- Place holder for HAVE_CGROU_SUPPORT definition
* src/mono/mono/metadata/icall.c
* src/mono/mono/sgen/sgen-marksweep.c
* src/mono/mono/sgen/sgen-simple-nursery.c
- Use mono_cpu_limit() instead of mono_cpu_count()
* src/mono/mono/utils/CMakeLists.txt
- Add mono-cgroup.c to the build
* src/mono/mono/utils/memfuncs.c
- Call `getRestrictedPhysicalMemoryLimit()` or `getPhyscalMemoryAvail()`
* src/mono/mono/utils/memfuncs.h
- Add prototypes for the new APIs
* src/mono/mono/utils/mono-cgroup.c
- Code adapted from coreCLR to interrogate sysfs to determine any limitations on memory or CPU
* src/mono/mono/utils/mono-proclib.c
- Add call to `getCpuLimit()`
* src/mono/mono/utils/mono-proclib.h
- Add prototype for the new API
@ghostghost added area-Build-mono community-contribution Indicates that the PR has been added by a community member labels Aug 19, 2022
@nealef
nealef marked this pull request as ready for review August 23, 2022 08:56
Comment threadsrc/mono/mono/utils/memfuncs.c
@naricc

Copy link
Copy Markdown
Contributor

If this code is adapated from CoreCLR, is there a plan to share the code eventually, or need it all be duplicated?

Comment threadsrc/mono/mono/utils/mono-proclib.h
Comment threadsrc/mono/mono/utils/mono-proclib.c Outdated
Comment threadsrc/mono/mono/utils/mono-cgroup.c
Comment threadsrc/mono/mono/utils/mono-proclib.c Outdated
Comment threadsrc/mono/mono/utils/mono-proclib.c Outdated
Comment threadsrc/mono/mono/utils/mono-proclib.c Outdated
Comment threadsrc/mono/mono/utils/mono-proclib.h Outdated
Comment threadsrc/mono/mono/utils/memfuncs.c Outdated

@lambdageeklambdageek left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@SamMonoRT I think we want to take a backport of this for net7. I don't think this will impact mobile or wasm. (But the "DOTNET_PROCESSOR_COUNT" support might be a nice thing to bring along on those platforms for diagnostic scenarios)

@SamMonoRT

Copy link
Copy Markdown
Member

@SamMonoRT I think we want to take a backport of this for net7. I don't think this will impact mobile or wasm. (But the "DOTNET_PROCESSOR_COUNT" support might be a nice thing to bring along on those platforms for diagnostic scenarios)

Yes, once all suggestions are addressed and CI lanes look green, will issue a backport command.

@SamMonoRT

Copy link
Copy Markdown
Member

@nealef - please let us know when all suggested changes are completed.

@nealef

Copy link
Copy Markdown
ContributorAuthor

The only one missing is the explicit cast from strtol(). I am having VPN problems today so I haven't been able to push. All other suggestions should have been pushed.

 - Adhere to call statement convention
- Remove unnecessary cast
* mono-proclib.c
- Explicit cast
Comment threadsrc/mono/mono/utils/mono-proclib.c Outdated
Comment threadsrc/mono/mono/utils/mono-proclib.h
@akoeplinger
akoeplinger merged commit 5119157 into dotnet:mainAug 31, 2022
@akoeplinger

Copy link
Copy Markdown
Member

/backport to release/7.0

@github-actions

Copy link
Copy Markdown
Contributor

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/2965665895

@ghostghost locked as resolved and limited conversation to collaborators Oct 1, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-VM-meta-monocommunity-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@nealef@naricc@SamMonoRT@akoeplinger@lambdageek@teo-tsirpanis