Guard against -1 Returned from sysconf for the Cache Sizes Causing Large Gen0 Sizes and Budgets for Certain Linux Distributions.

[mrsharm]

Issue Summary

• GetLogicalProcessorCacheSizeFromOS retrieves a bogus value of SIZE_MAX (-1 but type casted to a size_t) from the sysconf call for the L4 Cache Size that's now recognized has the last cache size (as it's not 0) causing a significantly larger gen0 size and budget for Debian 12 vs. Debian 11 for the same hardware i.e., same cache sizes, architecture etc. This behavior also seems to show up for Ubuntu 22.04.
• This is confirmed by running getconf -a | grep LEVEL4_CACHE on a Debian 12 (and an Ubuntu 22.04) machine results in an empty string for the L4 cache size - this is different from the behavior of Debian 11 that returns a 0 for the L4 cache size.
• SIZE_MAX from GetLogicalProcessorCacheSizeFromOS is also returned from GetCacheSizePerLogicalCpu and causes an extremely large gen0 size thereby affecting the gen0 budget for Server GC.

Further Details

Running getconf -a | grep LEVEL4_CACHE Outputs:

Debian 11

LEVEL4_CACHE_SIZE 0
LEVEL4_CACHE_ASSOC 0
LEVEL4_CACHE_LINESIZE 0

Debian 12

LEVEL4_CACHE_SIZE
LEVEL4_CACHE_ASSOC
LEVEL4_CACHE_LINESIZE

---

Ubuntu 20.04

LEVEL4_CACHE_SIZE 0
LEVEL4_CACHE_ASSOC 0
LEVEL4_CACHE_LINESIZE 0

Ubuntu 22.04

LEVEL4_CACHE_SIZE
LEVEL4_CACHE_ASSOC
LEVEL4_CACHE_LINESIZE

How To Detect This Issue

Run getconf -a | grep LEVEL4_CACHE and observe if the value for the LEVEL4_CACHE is empty or 0. If it is empty, it indicates that sysconf will return -1 and therefore, we will be susceptible to a large gen0 size and not if it's 0.

Solution

• Guard against -1 from being returned from sysconf that we cast to a size_t and therefore becomes SIZE_MAX to prevent much larger gen0 sizes and budgets than if -1 wasn't returned from sysconf.

Testing

First, we confirmed that running a standalone C program on Debian 11 vs. Debian 12 with code:

#include <unistd.h>
#include <stdio.h>

int main (int argc, char **argv) {
    printf( " Raw LEVEL4 Cache Size: %lu \n",  sysconf( _SC_LEVEL4_CACHE_SIZE ));
    return 0;
}

Results in:

Debian 11:
Raw LEVEL4 Cache Size: 0

Debian 12:
Raw LEVEL4 Cache Size: 18446744073709551615 or SIZE_MAX

Ubuntu 22.04:
Raw L4 Cache Value: 18446744073709551615 or SIZE_MAX

Additionally, with this fix, the customer confirmed that this fix resulted in their memory going back to previous levels.

[Maoni0]

                cacheSize = std::max(cacheSize, size);

what if size is SIZE_MAX here?

---

Refers to: src/coreclr/gc/unix/gcenv.unix.cpp:925 in 5868885. [](commit_id = 5868885, deletion_comment = False)

[mrsharm]

                cacheSize = std::max(cacheSize, size);

what if size is SIZE_MAX here?

Refers to: src/coreclr/gc/unix/gcenv.unix.cpp:925 in 5868885. [](commit_id = 5868885, deletion_comment = False)

Guarding against this now by rejecting any 0 or SIZE_MAX values here.

[jkotas]

Looks good to me as a minimal delta fix for servicing backport.

(I do not particularly like how some of the local variables are used in the macro, but others are not. It makes the code hard to follow. Cleaning it up is not necessary for the servicing fix.)

[mrsharm]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/8533880062

[mrsharm]

/backport to release/8.0-staging

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8533996443

[janvorli]

I do not particularly like how some of the local variables are used in the macro, but others are not. It makes the code hard to follow.

I completely agree that it would be good to eventually clean this up. Macros using ambient stuff are always difficult to follow, debug and reason about.

[mrsharm]

Looks good to me as a minimal delta fix for servicing backport.

(I do not particularly like how some of the local variables are used in the macro, but others are not. It makes the code hard to follow. Cleaning it up is not necessary for the servicing fix.)

Addressed: #100596

[debracey]

Possibly cause of

dotnet/aspnetcore#54405