Correct minimum memory size value from 200MB to 20MB

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).

[nealef]

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

[janani66]

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

[akoeplinger]

/backport to release/7.0

[github-actions]

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

[vargaz]

What is the customer impact of this fix ?

[janani66]

.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:

runtime/src/coreclr/gc/gcpriv.h

Lines 4062 to 4067 in a6f4527

	// 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]

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]

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).