- 
                Notifications
    You must be signed in to change notification settings 
- Fork 4
[upstream] transparent Item movement #92
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
base: main
Are you sure you want to change the base?
Conversation
e33e0fb    to
    14b6829      
    Compare
  
    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.
Reviewable status: 0 of 11 files reviewed, 1 unresolved discussion (waiting on @byrnedj and @igchor)
cachelib/common/Mutex.h line 344 at r1 (raw file):
using ReadLockHolder = ReadLockHolderType; using WriteLockHolder = WriteLockHolderType; using LockHolder = std::unique_lock<Lock>;
It looks like a workaround because WriteLockHolderType does not support try_lock.
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 would be nice to have some high-level overview of the algorithm in the commit description.
| // we rely on moving flag being set (it should block all readers) | ||
| XDCHECK_EQ(item.getRefCount(),0); | ||
| XDCHECK(item.isMoving()); | ||
| return item.isMoving(); | 
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 probably just return true here, right? no need to check the isMoving in Release
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.
Yeah. My strategy was to extract code from develop as is and use this PR to discuss excessive XDCHECK. I believe Daniel added them when investigated data race issues.
In that particular case there are two possible simplifications:
- remove checks and just return item.isMoving();
- hardcode to always return trueand keep checks.
|  | ||
| size_t wakeUpWaitersLocked(folly::StringPiece key, WriteHandle&& handle); | ||
|  | ||
| class MoveCtx { | 
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.
nit: This class can probably be implemented in CacheALlocator-inl.h
| XDCHECK(item->isChainedItem() | ||
| ? item->asChainedItem().getParentItem(compressor_).isMoving() | ||
| : item->isMoving()) << item->toString() << "\n" << syncItem->toString(); | ||
| if ( ( item->isChainedItem() && | 
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.
When can this happen?
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 think just XDCHECK(syncItem->isMoving()); is enough. All other checks are just duplications.
| XDCHECK(oldItem.isChainedItem() && oldItem.getRefCount() == 1); | ||
| XDCHECK_EQ(0, parentItem->getRefCount()); | ||
| newItemHdl = | ||
| allocateChainedItemInternal(*parentItem, oldItem.getSize()); | 
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 think we need to call allocateNewItemForOldItem function for chained items as well. And modify allocateNewItemForOldItem function to work correctly with chained items.
dcce4be    to
    955fbe7      
    Compare
  
    3824795    to
    ba3f5b5      
    Compare
  
    |  | ||
| std::memcpy(newItem.getMemory(), oldItem.getMemory(), oldItem.getSize()); | ||
| ++numMoves; | ||
| }, {}, 1000000 /* lots of moving tries */); | 
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 change this?
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 change just returns the test to the initial state (like in main branch).
@byrnedj increased the number of tries, but after various fixes looks like it is not required anymore.
c0ecd6d    to
    ab70b7d      
    Compare
  
    635eb22    to
    bada673      
    Compare
  
    The new algorithm relies on the moving bit and does not require external synchronization. Data movement happens transparently for the client: if the client thread attempts to get a handle for the item being moved it will get a handle with wait context to wait till the movement is completed.
bada673    to
    807dbda      
    Compare
  
    807dbda    to
    3d73cfe      
    Compare
  
    Use findInternal instead of acquire
I was able to extract code changes related to transparent data movements.
No testing was done yet. I just make sure that the code is compiled.
I extracted code almost as-is from develop branch. I will use this PR to discuss possible refactoring - I will put comments to the appropriate code lines.
This change is