-
Notifications
You must be signed in to change notification settings - Fork 24
feat(deferred-persist): Part 1: unpersisted gauge #1116
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
Conversation
dff9f97 to
aaf968f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
56826d7 to
e53e961
Compare
308f06a to
7b4c667
Compare
7b4c667 to
bb4826f
Compare
| unwritten_nodes: AtomicUsize::new( | ||
| self.unwritten_nodes | ||
| .load(std::sync::atomic::Ordering::Relaxed), | ||
| ), |
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.
Confirming that this is intentional the the cloned committed is using a new atomic integer and isn't re-using the integer from the previous cloned. The diverging committed nodes will have different unwritten_nodes counts.
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.
Good catch, it's not correct. I'll remove this code as it's dead anyway; we never clone Committed.
|
|
||
| let immutable_proposal = | ||
| Arc::into_inner(nodestore.kind).expect("no other references to the proposal"); | ||
| // Use ManuallyDrop to prevent Drop from running since we're replacing the proposal |
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.
can you expand the comment to explain the implications of not using ManuallyDrop here?
storage/src/nodestore/persist.rs
Outdated
| // Decrement gauge for writes that have actually completed | ||
| if completed_writes > 0 { | ||
| #[expect(clippy::cast_possible_truncation)] | ||
| #[expect(clippy::cast_possible_truncation, clippy::cast_precision_loss)] |
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.
not understanding the lint problems here. some targets are triggering it and some aren't.
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.
let's switch to allow and I'll research this next week (#1135)
Added a gauge to track the number of unpersisted nodes at any time. These can get used later by the revision manager to decide whether or not to persist a proposal (among other possible strategies). It's also helpful to know how many nodes are still in memory that could be persisted. When increasing this counter, we do it all at once, but we decrement one by one (or by the number of entries from the kernel's completion queue). This is because the writes are slower than the adds, and there is some integer to floating point math that happens each time the counter is adjusted.
8dcfe36 to
57cdd41
Compare
These seem to confuse clippy in CI
900779f to
1ea7a63
Compare
Co-authored-by: Brandon LeBlanc <brandon.leblanc@avalabs.org>
The use of ManuallyDrop seems to cause a leak. Let's fix this correctly later.
The use of ManuallyDrop seems to cause a leak. Let's fix this correctly later.
No description provided.