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

Correct minimum memory size value from 200MB to 20MB #77682

Merged
merged 1 commit into from
Nov 1, 2022
Merged

Correct minimum memory size value from 200MB to 20MB #77682

merged 1 commit into from
Nov 1, 2022

Conversation

nealef
Copy link
Contributor

@nealef nealef commented Oct 31, 2022

Typo caused value to be 200MB instead of 20MB.

@vargaz vargaz merged commit 7d5efbb into dotnet:main Nov 1, 2022
@janani66
Copy link

janani66 commented Nov 1, 2022

@vargaz -- Can this be included in .NET7 Service branch

@akoeplinger
Copy link
Member

/backport to release/7.0

@github-actions
Copy link
Contributor

github-actions bot commented Nov 2, 2022

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

@vargaz
Copy link
Contributor

vargaz commented Nov 7, 2022

What is the customer impact of this fix ?

@janani66
Copy link

janani66 commented Nov 7, 2022

.NET 6.0+ on s390x does not understand memory and cpu limits in containers.
Without this patch, on s390x and ppc64le memory and cpu limits in containers may not be honored - it is possible that .NET will try to use more memory than allocated to the container, causing the container to get killed or restarted.

The corresponding place in CoreCLR, where minimum memory size is set to 20M is:

// If the GCHeapHardLimit config is specified that's the value we use;
// else if the GCHeapHardLimitPercent config is specified we use that
// value;
// else if the process is running inside a container with a memory limit,
// the hard limit is
// max (20mb, 75% of the memory limit on the container).

and the implementation at around line 45176 in src/coreclr/gc/gc.cpp:

// If the hard limit is specified, the user is saying even if the process is already
// running in a container, use this limit for the GC heap.
if (gc_heap::heap_hard_limit)
{

#ifdef FEATURE_EVENT_TRACE
gc_heap::hard_limit_config_p = true;
#endif //FEATURE_EVENT_TRACE
}
else
{
if (gc_heap::is_restricted_physical_mem)
{
uint64_t physical_mem_for_gc = gc_heap::total_physical_mem * (uint64_t)75 / (uint64_t)100;
gc_heap::heap_hard_limit = (size_t)max ((20 * 1024 * 1024), physical_mem_for_gc);
}
}
The patch implements the obvious fix to change to 20 MB in Mono as well

@nealef
Copy link
Contributor Author

nealef commented Nov 7, 2022

There is a fix in for .NET 7. s390x doesn't use the CoreCLR runtime so it was recreated for mono. I doubt it will be backported to .NET 6 but that's not my call.

@uweigand
Copy link
Contributor

uweigand commented Nov 8, 2022

Note that the main code change to respect per-container CPU and memory limit is already in .NET 7. However, that current implementation (erroneously) always allows the container to use at least 200MB, while the intended lower limit was supposed to be 20MB. This PR simply corrects that mistake.

The customer impact of missing this PR depends on the particular customer scenario. Of course, if a customer only runs containers of size 200MB or larger, there is no impact. But if a customer intends to run many very small containers on a single system, then the erroneous lower limit of 200MB might cause overall memory resources to be exhausted, leading to out-of-memory scenarios (e.g. containers being killed).

@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants