Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors.#109749

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@mrsharm
Copy link
Member

@mrsharmmrsharm commentedNov 12, 2024
edited
Loading

.NET 9 port of:#108492 - full details about the problem, solution and how to detect this issue can be found there.

Customer Impact

  • Customer reported
  • [] Found internally

Certain AMD Processor SKUs suffer from the issue where the output of sysconf, the mechanism to discern the last level cache size, returns the value of the last level cache of the host rather than the VM or container. An example of the processor is: AMD EPYC 7763.

The impact of a larger than expected last level cache size is a larger Gen0 budget and thereby, a larger memory footprint albeit, fewer GCs than if the last level cache size is smaller.

We have provided a new configuration:DOTNET_GCCacheSizeFromSysConf that can be set to 1 to revert to the old logic.

Regression

  • Yes
  • No

The regression in behavior relative to other processors which don't exhibit this behavior.

Testing

Tested with an internal customer.

Risk

High risk as this affects the behavior of how the min and max gen0 budget is calculated for Unix based runtimes that has a significant effect on how the GC behaves.

@dotnet-policy-service
Copy link
Contributor

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

@jeffschwMSFTjeffschwMSFT added the Servicing-considerIssue for next servicing release review labelNov 13, 2024
Copy link
Member

@jeffschwMSFTjeffschwMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

lgtm. we will take for consideration in 9.0.x

@jeffschwMSFTjeffschwMSFT added this to the9.0.x milestoneNov 13, 2024
@jeffschwMSFTjeffschwMSFT added Servicing-approvedApproved for servicing release and removed Servicing-considerIssue for next servicing release review labelsNov 25, 2024
@jeffschwMSFTjeffschwMSFT modified the milestones:9.0.x,9.0.1Nov 25, 2024
@mrsharmmrsharm merged commit9f23ddb intodotnet:release/9.0-stagingNov 26, 2024
92 of 96 checks passed
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsDec 26, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes

@Maoni0Maoni0Maoni0 approved these changes

@mangod9mangod9Awaiting requested review from mangod9

@cshungcshungAwaiting requested review from cshung

@markplesmarkplesAwaiting requested review from markples

Assignees

@mrsharmmrsharm

Labels

area-GC-coreclrServicing-approvedApproved for servicing release

Projects

None yet

Milestone

9.0.1

Development

Successfully merging this pull request may close these issues.

3 participants

@mrsharm@jeffschwMSFT@Maoni0

[8]ページ先頭

©2009-2025 Movatter.jp