[release/8.0-staging] Guard against -1 Returned from sysconf for the Cache Sizes Causing Large Gen0 Sizes and Budgets for Certain Linux Distributions.

[github-actions]

Backport of #100502 to release/8.0-staging

/cc @mrsharm

Customer Impact

• Customer reported
• Found internally

All runtimes running server GC running on Linux distributions that return -1 for the LEVEL4_CACHE_SIZE from sysconf are affected by the underlying issue that this PR addresses. The implications of this issue are that the gen0 budget is computed as a function of the total memory available and not the L3 cache size as before for certain Linux distributions such as Debian 12, and Ubuntu 22.04. Relying on the physical memory which is much larger than the L3 cache size results in extremely large gen0 budgets and thereby causing larger heap sizes and consequently, more memory utilization.

The internal customer impact reduced their overall memory utilization from 1 GB to 300 MB and were satisfied with the result.

Regression

• Yes
• No

This regression is as a result of changes to the result of sysconf for certain Linux distributions. The result that we are now guarding against is -1. The code that introduced this behavior by not vetting the output of sysconf (a long) and casting it to a size_t was: #71029; this was in the .NET 7 timeframe but probably didn't emanate to our user base since the values of sysconf for the L4 Cache Size for newer distributions started showing up as -1 if they didn't exist and where in previous cases such as for Debian 11, they had been 0. This was confirmed from running getconf -a | grep CACHE on multiple distributions of Linux and the ones that exhibited this behavior e.g., Debian 12 indicated that there had been a change in the behavior by outputting -1.

Testing

• The fix was tested on an internal customer, and we confirmed that the Gen0 budgets were equivalent to that of the baseline. In the regressed case, they were a factor of > x10 the original budget and therefore, the memory utilization increased by that factor. We observed from the traces a decrease in the heap size and the gen0 budget of a factor of 10.

Risk

The risk of the fix is high as the code path is called for all SVR instances for Linux. However, this is a fix for an already existing issue and has been tested and verified.

Full Details can be found: #100502

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[janvorli]

LGTM, thank you!

[jkotas]

The result that we are now guarding against is -1

FWIW, @Maoni0 noticed that the error handling is not right during codereview two years ago: #71029 (comment) . Unfortunately, this feedback was not followed up upon.

[jeffschwMSFT]

approved. we will take for consideration in 8.0.x

[mrsharm]

The build failures are known issues: #100035 => This PR can be merged as the errors aren't related.

[ericstj]

/ba-g all failures were classified as Known but the check did not flip to green.