Fix distribute free regions #74916
Fix distribute free regions #74916
Conversation
… has between budget-1 and budget regions.
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsAs it turns out, distribute_free_regions does not do a very good job distributing free regions if there are fewer than the budget demands. There are two reasons:
The fix corrects the computation and (somewhat inelegantly) adds yet another pass to the distribution algorithm:
This should guarantee that each heap has either budget-1 or budget number of regions. I also adjusted the computation of min_gen0_balance_delta - that is subject to further testing.
|
…e the correction evenly over all the heaps. This makes the budget correction pass more expensive, but enables us to remove extra pass at the end.
…heaps, disregard higher generation budgets if the free regions are only sufficient for lower ones. Enhance instrumentation for decommit_ephemeral_segment_pages.
…t per heap which is the budget for the highest generation covered by the available free regions. When distributing a budget shortfall for a higher generation, avoid going lower than the minimum. Example: assume we have 21 free regions available, heap 0 needs 10 in gen 0 and 0 in gen 1, while heap 1 needs 10 in gen 0 and 3 in gen 1. So our budget for gen 0 is 20 regions, which is covered by the available free regions, while the budget for gen 0 + gen 1 is 23 regions, so we have a shortfall of 2 regions compared to the available free regions. As the gen 1 budget is less reliable and its use further in the future, it's better to give heap 0 10 regions and heap 1 11 regions, rather than reducing the budget by 1 region each, which would mean giving 9 regions to heap 0 and 12 regions to heap 1.
src/coreclr/gc/gc.cpp
Outdated
| size_t num_decommit_regions_by_time = 0; | ||
| size_t size_decommit_regions_by_time = 0; | ||
| size_t heap_budget_in_region_units[MAX_SUPPORTED_CPUS][kind_count]; | ||
| size_t min_heap_budget_in_region_units[MAX_SUPPORTED_CPUS][kind_count]; |
There was a problem hiding this comment.
since we are only using this for SOH, it seems like this can just be declared as
size_t min_heap_budget_in_region_units[MAX_SUPPORTED_CPUS];
MAX_SUPPORTED_CPUS is 1024 so this is quite a large data structure.
There was a problem hiding this comment.
Well, we are using it for UOH as well, but it's always 0 in this case, so we can use an if-statement or conditional expression.
I'll fix it...
Maoni0
left a comment
Maoni0
left a comment
There was a problem hiding this comment.
other than the comment I have above, the rest LGTM
…wice as large as it needs to be as the slots for kind == 1 will always be 0.
|
new changes LGTM! |
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3153046300 |
ghost
locked as resolved and limited conversation to collaborators
2 participants
As it turns out, distribute_free_regions does not do a very good job distributing free regions if there are fewer than the budget demands. There are two reasons:
The fix corrects the computation and (somewhat inelegantly) adds yet another pass to the distribution algorithm:
This should guarantee that each heap has either budget-1 or budget number of regions.
I also adjusted the computation of min_gen0_balance_delta - that is subject to further testing.