-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[release/7.0] Gradual decommit in wks #76306
Conversation
This is the regions version modeled after the behavior of the segments version. Idea is simply to limit the amount of decommitted memory based on the time since the last GC.
…es the logic for the WKS decommit more straightforward.
…of decommitted regions.
…_segment_pages for WKS, some changes in distribute_free_regions as a consequence.
Tagging subscribers to this area: @dotnet/gc Issue DetailsBackport of #73620 to release/7.0 /cc @mangod9 @PeterSolMS Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
Customer ImpactThis addresses a performance regression from .NET 6.0 - with regions enabled, we decommit more aggressively, which causes us to recommit more memory later and incur page faults when that memory is touched for the first time. The effect has been seen with micro benchmarks, but will likely impact customer scenarios as well. TestingRan GCPerfSim scenarios and thousands of micro benchmarks with this change and verified it mostly (but not altogether completely) gets rid of the regression caused by more agressive decommit. RiskRisk is low because the fix only impacts when free regions get returned to the region allocator. When the allocator needs a new region, it can get it either from the list of free regions, or from the region allocator. Both code paths are well tested. Because the fix delays decommitting free regions, some increase in working set may be observed temporarily. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved. we will take for consideration in 7 ga.
@PeterSolMS can you please send an email to Tactics requesting approval? |
Installer failures look to be unrelated, but rerunning them now. |
I emailed tactics for @PeterSolMS |
Approved by Tactics via email. CI is green after re-run. Signed off. Ready to merge. |
Backport of #73620 to release/7.0
/cc @mangod9 @PeterSolMS
Customer Impact
This addresses a performance regression from .NET 6.0 - with regions enabled, we decommit more aggressively, which causes us to recommit more memory later and incur page faults when that memory is touched for the first time. The effect has been seen with micro benchmarks, but will likely impact customer scenarios as well.
Testing
Ran GCPerfSim scenarios and thousands of micro benchmarks with this change and verified it mostly (but not altogether completely) gets rid of the regression caused by more agressive decommit.
Risk
Risk is low because the fix only impacts when free regions get returned to the region allocator. When the allocator needs a new region, it can get it either from the list of free regions, or from the region allocator. Both code paths are well tested. Because the fix delays decommitting free regions, some increase in working set may be observed temporarily.
IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.