-
Notifications
You must be signed in to change notification settings - Fork 6
New mapped_private mode: avoid crash by flushing dirty pages when memory pressure gets high #24
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
Closed
Changes from 1 commit
Commits
Show all changes
30 commits
Select commit
Hold shift + click to select a range
91cf743
Bump required `cmake` version as suggested in PR #21.
greg7mdp 302274b
Cleanup compiler feature dependency as suggested in review of PR #21.
greg7mdp 2cf9842
Implement `check_memory_and_flush_if_needed` function
greg7mdp cf8ff37
Update threshold and comment.
greg7mdp 6663302
Return more data from `check_memory_and_flush_if_needed`
greg7mdp 3460d0e
Always return `oom` score if available.
greg7mdp 90c653b
Don't force immediate flush of all state dirty pages.
greg7mdp 11f9090
Disable `save` messages when processing `oom` event.
greg7mdp 6ee4f83
Recreate copy_on_write mapping after disk file is updated.
greg7mdp ba91bc2
Destroy old region before creating a new one.
greg7mdp 664b069
Use `mmap` with `MAP_FIXED` to ensure we get the same address
greg7mdp febb50c
Don't use mmap/munmap when _WIN32 is defined.
greg7mdp c55e62e
Use `_cow_size` consistently.
greg7mdp 923444c
Remove unnecessary `_cow_size` and rename a couple new variables.
greg7mdp b782713
Update return value of `check_memory_and_flush_if_needed`
greg7mdp 34a5033
Check for empty `std::optional` before returning `oom_post`.
greg7mdp 408af79
Add test exercising the `flush` of dirty pages when the `oom` score g…
greg7mdp e63909f
Skip `munmap` to avoid race condition between `munmap` and `mmap`.
greg7mdp 1e56487
Fix mismatched sign comparison.
greg7mdp 580a743
Small cleanup; add wait in test for accurate soft-dirty bit read.
greg7mdp 1819359
Merge branch 'main' of github.com:AntelopeIO/chainbase into gh_1721
greg7mdp 930611e
Update test to insert in the db right after doing `clear_refs`.
greg7mdp 113f0be
Add db consistency check after flush in test.
greg7mdp f6343e7
Fix wrong delay in test, and remove unnecesary wait.
greg7mdp 3e11aa8
Remove unnecessary `cerr` output in test.
greg7mdp 1160b4f
Merge branch 'main' into gh_1721
greg7mdp b9968ed
Make oom test work on systems that don't support oom.
greg7mdp 63b76dc
Fix issue with incorrect `database_size` when requesting a smaller `s…
greg7mdp 734dc46
Check for `mmap` failing (could happen if RAM size < database_size).
greg7mdp 7b9a4f0
Make whitespace change for `_database_size` fix same as in `[5.0]` PR.
greg7mdp File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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.
Are you saying clearing the bits is asynchronous? If that's the case the whole approach seems dangerous.
I was initially worried about that when doing the initial review, but when I looked through the kernel source it seemed like it was synchronous.
Or instead is the problem here in this test that the
oom_score
is only updated at some interval and we need to wait around for that update to occur? If that's the case, I don't think citing thatsoft-dirty.txt
refers to the same issue.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.
The issue is not updating the oom_score (in the test we don't care about the value being updated because we set an arbitrarily low threshold).
It seems that if you check for the soft-dirty bits on the pages right after clearing them, you don't get correct results.
The reason I linked this url is:
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.
It seems that when we don't wait, we see more pages as dirty as we should, so I don't think it is dangerous, except for the fact that we'd flush more pages to disk than strictly needed. But I agree that it is unnerving.
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.
It's dangerous because if it's not synchronous you'll miss writes that occur on pages after writing to
clear_refs
but before the dirty bit is cleared asynchronously in the background.After
save_database_file()
we should have completely fresh pages anyways though right? So why are we seeing seemingly spurious dirty bits in brand new pages? Is it possible the dirty bit is only valid based on some other criteria? (some other bit being set?)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.
If it behaved like that the feature would be utterly useless.
No I don't think so because all we need to do is wait a second or two and then we see the correct pages dirty.
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.
I have tested it and you don't miss writes.
If you write to a page right after
clear_refs
, yo see the dirty bit whether you check right after theclear_refs
, or two seconds later.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.
Why do the kernel unit tests not require waiting?
Uh oh!
There was an error while loading. Please reload this page.
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.
Hum, the test doesn't check exactly the same thing. The check has one page with the soft-dirty bit set and verifies that the bit is cleared immediately after
clear_refs
.What I see in my test is that newly mapped pages, which were never written to, report being
soft-dirty
for a second or two afterclear-refs
, and then don't anymore. But if one of these pages is written to immediately afterclear-refs
, thesoft-dirty
bit will remain set.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.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/mm/soft-dirty.c?h=v6.5.7#n127
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.
@spoonincode you are correct, there was an issue in the test (now corrected) that made me think that
clear_refs
did not clear thesoft-dirty
bit immediately, but that was an error on my part. So my original comment was wrong, the clearing of thesoft-dirty
bits is synchronous.