Merged
Conversation
ed65f46 to
2b94e22
Compare
8 tasks
2b94e22 to
f80a8a9
Compare
Member
|
this changes the way we survive pretty dramatically, ie, it no longer allows variability in DoSurvive. this issue is to track getting that ability back. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Built on the previous fix, this PR fixes the wrong bucket weight computation. The change is going to be much easier to review once we have done with the previous fix first.
Here are some experiments I ran to show how the weight computation fix works.
This is the base command line:
-tc 6 -tagb 80.0 -tlgb 0.2 -sohsi 30 -lohsi 0 -pohsi 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohpi 50 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind timeNote that the allocation ratio arguments are not given above, we will vary them in the following cases:
Case 1:
-lohar 10 -pohar 20Without fix:
sohAllocatedBytes: 17387864196 (20.24%)
lohAllocatedBytes: 22174926546 (25.81%)
pohAllocatedBytes: 46337496222 (53.94%)
With fix:
sohAllocatedBytes: 83407696230 (97.10%)
lohAllocatedBytes: 862837482 (1.00%)
pohAllocatedBytes: 1628816178 (1.90%)
It can be easily seen that the weight was wrong by a large margin, and the fix corrected it.
Case 2:
-lohar 100 -pohar 200Without fix:
Crashes with
System.Exception: Values are not closeWith fix:
sohAllocatedBytes: 60546753948 (70.49%)
lohAllocatedBytes: 8375351532 (9.75%)
pohAllocatedBytes: 16977259434 (19.76%)
This repros the
Values are not closeproblem in the base case.Case 3:
-lohar 200 -pohar 100Without fix:
Crashes with System.Exception:
Values are not closeWith fix:
Crashes with System.Exception:
Values are not closeThe last experiment indicates the bug is not completely fixed, it repros even in the new version, so this is incomplete work, but the original implementation was off by so much that I would like to merge in this partial fix first.