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.
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
feat(storage): wake up memory acquire request in order #15921
feat(storage): wake up memory acquire request in order #15921
Changes from 6 commits
0f24619
cea0606
9de6dcc
66aabc5
c69ad89
8f51202
241a2fb
93f608d
b6ae16b
ce102f4
b46bf76
efa24f4
df6f40d
11fc843
e33824f
22188ed
3bd9ad5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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
MemoryTrackerImpl
and the newly addedPendingRequestCancelGuard
seem to be an over-design for the corner case mentioned above. Let's analyze all the cases when quota is acquired:MemoryRequest::Ready
(L287), we need to release the quota and notify waiters.may_notify_waiters
in L243, there are two sub-cases:a.
tx.send
here succeeds, regardless of whether the rx is dropped or not, we need to release quota and notify waiter.b.
tx.send
here fails (due to rx has been dropped before tx.send). we only need to release quota but not notify watier (Otherwise, it will deadlock).Therefore, the implementation can be greatly simplified without introducing
MemoryTrackerImpl
andPendingRequestCancelGuard
.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.
We can not send
MemoryTracker
with in lock ofcontroller
because if it drops in this method, it may callmay_notify_waiters
again, which would acquire one lock twice.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.
We met this bug in #6634
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 tokio-rs/tokio#6558 looks good from the tokio community, we can have a patch on the tokio version we are using, and then we can adopt the code in this comment.
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 we move this fast path code
self.try_require_memory_in_capacity(quota, self.fast_quota)
to before acquiring the lock? In this way, if we successfully acquire the quota via CAS, we can avoid locking and writing the atomic variable.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.
This method is always called before
try_require_memory
, it means that has a failed try by CAS without lockThere 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.
We must try to acquire with lock, because if there is no tracker hold by other threads, we can not notify this waiter forever.
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.
Maybe we can optimize the case when there are concurrent drops in multiple threads.
A rough idea will be, each thread will try to set the
pending_request_count
to 0 via CAS in a loop, and the only one that successfully sets it to 0 will do the notification.