Skip to content

Upstreaming plan (5/4/2022) #68

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.

Sign up for GitHub

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

Jump to bottom
Closed
victoria-mcgrath opened this issue May 5, 2022 · 0 comments
Closed

Upstreaming plan (5/4/2022) #68

victoria-mcgrath opened this issue May 5, 2022 · 0 comments

Comments

@victoria-mcgrath
Copy link
Collaborator

victoria-mcgrath commented May 5, 2022 •
edited by guptask
Loading

<style> </style>

Design overview:  facebook#102

 

Grouping Description Intel PR Meta PR Notes
Independent preparatory changes        
  Shortened critical section   facebook#132 Performance improvement
  Per-pool cache stats  facebook#141 Benchmarking stats improvement
  Add value validation to cachebench   facebook#131 Benchmarking improvement
  Alternative locking approach for item movement #36   Performance improvement
  File-mapped memory support in shared memory manager facebook#146 Enables access to PMEM memory
  Initial set of changes to config API   facebook#138 First mention of memory tiers, only one DRAM tier is allowed
Tiers enabling changes        
  Enable tiers in allocator TBD   The feature is complete on the Intel  fork
  Enable tiers in config API TBD   The feature is complete on the Intel  fork
  Enable multi-tier eviction TBD   The feature is complete on the Intel  fork
Future work        
  Scalable eviction policy TBD   Partition 2Q into independent structures so they use separate locks per region
  Background eviction thread TBD   Performance improvement
@igchor igchor closed this as completed Feb 7, 2023
byrnedj pushed a commit to byrnedj/CacheLib that referenced this issue Mar 17, 2023
@igchor
Fix race in acquire (pmem#68)
f4e30a7 
The assumption for moving items was that once item is unmarked no one
can add new waiters for that item. However, since incrementing item ref
count was not done under the MoveMap lock, there was a race: item could
have been unmarked right after incRef returned incFailedMoving.
byrnedj pushed a commit to byrnedj/CacheLib that referenced this issue Jul 24, 2023
@igchor @byrnedj
Fix race in acquire (pmem#68)
6abb498 
The assumption for moving items was that once item is unmarked no one
can add new waiters for that item. However, since incrementing item ref
count was not done under the MoveMap lock, there was a race: item could
have been unmarked right after incRef returned incFailedMoving.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@igchor @victoria-mcgrath