-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Refactor segment size computation #71178
Conversation
Tagging subscribers to this area: @dotnet/gc Issue Detailsnull
|
28860e2
to
d59a0a8
Compare
you'd need to do a bit more work than just mechanically copying code.... I pushed a branch here: https://github.com/Maoni0/runtime/tree/soh_seg_size. note I just wrote this code. I haven't tried to compile it. this is just illustrating the idea of refactoring. the result caller looks like this
|
bb098ef
to
53e10e0
Compare
This change fixes the working set regression when running the JSON TechEmpower benchmark on Windows under a container. Here is a summary of the performance data:
Segments:
Max Working Set (MB) | 134
Regions before fix:
Max Working Set (MB) | 339
Regions after fix:
Max Working Set (MB) | 135
There is no significant difference between regions after fix and segment on other metrics we measured.
Cause of the regression:
The concept of SOH segment sizes does not exists on regions, but since the variable
soh_segment_size
is used in various performance tuning functions, we were hard coding that to 4G for workstation GC and 1G for server GC. It was mostly okay, but in an extreme situation like in this benchmark, we have only 512MB of memory but we are running on a machine with 28 cores => 28 heaps. Thesoh_segment_size
is reduced significantly in the segment's case but we still use the same value under the region's case. This causes the performance tuning function to behave very differently and leads to regression.Solution:
We keep the existing computation of the
soh_segment_size
logic under regions so that it will get back to what it was.