-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Hazard Pointer Reclamation - Unlock Tagged list faster #2106
Open
instw
wants to merge
1
commit into
facebook:main
Choose a base branch
from
instw:export-D51638674
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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 pull request was exported from Phabricator. Differential Revision: D51638674 |
This pull request was exported from Phabricator. Differential Revision: D51638674 |
instw
force-pushed
the
export-D51638674
branch
from
January 22, 2024 19:30
18a1822
to
30615d5
Compare
instw
pushed a commit
to instw/folly
that referenced
this pull request
Jan 22, 2024
Summary: PROBLEM During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for `tagged_`). There is opportunity to improve the performance of reclamation, by keeping the `tagged_` list locked for a smaller amount of time. SOLUTION The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the `tagged_` list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort. The locking of list is to guard against the `tagged_` list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed. Also validated that the `nomatch` handling is thread-safe - The cohort's `push_safe_obj` uses as CAS loop to safely add to the top of the list. Would multiple copies of an object be pushed into a cohort? No - An object is either in the retirement list (i.e. list) in the cohort, or it's been processed for reclamation. This guarantee already exists (the diff doesn't change that). This means the only way multiple copies of an object can be pushed back to the safe list is if we end up clearing the `tagged_` list within the domain - which is the synchronization / shared memory point. Since we do dequeue and enqueue of that list under a lock, an object should would never appear on that list. The only (shared object) change is around addition to the cohort's safe list, which is meant to be thread-safe. Reviewed By: yfeldblum Differential Revision: D51638674
This pull request was exported from Phabricator. Differential Revision: D51638674 |
1 similar comment
This pull request was exported from Phabricator. Differential Revision: D51638674 |
Summary: PROBLEM During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for `tagged_`). There is opportunity to improve the performance of reclamation, by keeping the `tagged_` list locked for a smaller amount of time. SOLUTION The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the `tagged_` list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort. The locking of list is to guard against the `tagged_` list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed. Also validated that the `nomatch` handling is thread-safe - The cohort's `push_safe_obj` uses as CAS loop to safely add to the top of the list. Would multiple copies of an object be pushed into a cohort? No - An object is either in the retirement list (i.e. list) in the cohort, or it's been processed for reclamation. This guarantee already exists (the diff doesn't change that). This means the only way multiple copies of an object can be pushed back to the safe list is if we end up clearing the `tagged_` list within the domain - which is the synchronization / shared memory point. Since we do dequeue and enqueue of that list under a lock, an object should would never appear on that list. The only (shared object) change is around addition to the cohort's safe list, which is meant to be thread-safe. Reviewed By: yfeldblum Differential Revision: D51638674
instw
force-pushed
the
export-D51638674
branch
from
January 23, 2024 18:28
30615d5
to
f80275e
Compare
This pull request was exported from Phabricator. Differential Revision: D51638674 |
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.
Summary:
PROBLEM
During reclamation of tagged objects, we obtain a lock within the hazard pointer domain's tagged list. This list supports always pushing objects, but only allows popping when there is a lock (for
tagged_
).There is opportunity to improve the performance of reclamation, by keeping the
tagged_
list locked for a smaller amount of time.SOLUTION
The list is locked to prevent multiple threads from reclaiming the same objects. During reclamation, we take all objects that are potentially cleaned up, and divide them into 2 parts: Those that must be reclaimed, and those that must not. The ones that are not are pushed back to the
tagged_
list, and the list is unlocked. The objects to be reclaimed are freed - by pushing to the cohort.The locking of list is to guard against the
tagged_
list itself, and hence when we push the not-to-be-reclaimed elements back, we could theoretically release the lock without waiting for the reclaimed objects to finish being processed.Also validated that the
nomatch
handling is thread-safe - The cohort'spush_safe_obj
uses as CAS loop to safely add to the top of the list.Differential Revision: D51638674