Honor virtual memory limit #80295
Honor virtual memory limit #80295
Conversation
janvorli
added
NO-MERGE
|
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsThe coreclr runtime currently doesn't honor virtual memory size limit specified by the rlimit APIs (or the There were couple of cases in the past where people have hit this problem when trying to run .NET on systems where the administrators have applied virtual memory limit for all users as a simple mean to limit the physical memory usage. This change enables honoring that limit in the GC and PAL preallocator of the initial executable memory, as those two are the factors preventing coreclr execution on such systems.
|
janvorli
force-pushed
the
honor-virtual-memory-limit
branch
from
608b0c8 to
993ea84
Compare
src/coreclr/pal/src/map/virtual.cpp
Outdated
There was a problem hiding this comment.
I am not happy with this COMPlus env variable name. Any suggestions for better name are welcome.
src/coreclr/pal/src/map/virtual.cpp
Outdated
There was a problem hiding this comment.
It feels a bit strange to specify the percentage in hex, but it is the default we use for all COMPlus / DOTNET variables, including percentual settings in the GC.
There was a problem hiding this comment.
I don't know if it is architecturally feasible, but it would be nice if we don't need to proliferate the environment variable parsing rules.
|
Hey @janvorli -- I wanted to check in to see if this was still in progress, if it should be converted to draft, if it should be closed for now, or if you want to leave it as-is. Thanks! |
|
@jeffhandley it is marked as [WIP] and NO-MERGE, I have assumed it is the same as marking it as draft. I still want to finish this, I just got distracted by other important stuff. |
|
Cool; thanks for the update, @janvorli! |
|
Should we add a section to this doc on this topic (and generalize the title)? |
That makes sense. |
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsThe coreclr runtime currently doesn't honor virtual memory size limit specified by the rlimit APIs (or the There were couple of cases in the past where people have hit this problem when trying to run .NET on systems where the administrators have applied virtual memory limit for all users as a simple mean to limit the physical memory usage. This change enables honoring that limit in the GC and PAL preallocator of the initial executable memory, as those two are the factors preventing coreclr execution on such systems.
|
janvorli
force-pushed
the
honor-virtual-memory-limit
branch
2 times, most recently
from
22f1144 to
8dc8055
Compare
The coreclr runtime currently doesn't honor virtual memory size limit specified by the rlimit APIs (or the `ulimit -v` shell command). There were couple of cases in the past where people have hit this problem when trying to run .NET on systems where the administrators have applied virtual memory limit for all users as a simple mean to limit the physical memory usage. This change enables honoring that limit in the GC and PAL preallocator of the initial executable memory, as those two are the factors preventing coreclr execution on such systems.
janvorli
force-pushed
the
honor-virtual-memory-limit
branch
from
8dc8055 to
86db568
Compare
janvorli
removed
the
NO-MERGE
| set(CMAKE_REQUIRED_LIBRARIES) | ||
| check_cxx_source_runs(" | ||
| #include <fcntl.h> | ||
| #include <stdlib.h> | ||
| #include <stdio.h> | ||
| #include <unistd.h> | ||
| int main(void) { | ||
| int fd; | ||
| fd = open(\"/proc/self/statm\", O_RDONLY); | ||
| if (fd == -1) { | ||
| exit(1); | ||
| } | ||
| exit(0); | ||
| }" HAVE_PROCFS_STATM) |
There was a problem hiding this comment.
What's the point of checking this at build time, shouldn't the runtime not depend on whether the build machine exposes statm?
There was a problem hiding this comment.
This is to detect whether the OS supports that at all. We don't actually support /proc file system optionally on Linux. There is no other way to get the information we need there. We have similar checks in the PAL configure.cmake.
dotnet#80295 added a new entry to tryrun.cmake but iOS/tvOS use a separate tryrun_ios_tvos.cmake which was missing the new entry.
#80295 added a new entry to tryrun.cmake but iOS/tvOS use a separate tryrun_ios_tvos.cmake which was missing the new entry.
7 participants
The coreclr runtime currently doesn't honor virtual memory size limit specified by the rlimit APIs (or the
ulimit -vshell command).There were couple of cases in the past where people have hit this problem when trying to run .NET on systems where the administrators have applied virtual memory limit for all users as a simple mean to limit the physical memory usage.
This change enables honoring that limit in the GC and PAL preallocator of the initial executable memory, as those two are the factors preventing coreclr execution on such systems.