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
os/bluestore: simplify allocator release flow #12343
Conversation
@liewegas Will take this patch and apply multi kv_sync on top..Will keep you posted on this.. |
c5ecb76
to
fd6b8a1
Compare
rebased on latest master, which now includes the bitalloc dump |
@liewegas , looks good to me. |
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.
Looks good to me
@liewegas I am seeing some degradation after porting my multi kv_sync changes on top of these commits + latest master. Not sure if it is because of the allocator changes or something else (because I was working on probably 3 weeks old master). Will revert these commits and see. |
@liewegas , I think we should remove TBD comment in BitMapAllocator.cc for making commiting logic concurrent:
|
fd6b8a1
to
ce35496
Compare
Wait until after the kv transaction commits, and then release extents directly into the usable pool. This will let us remove the commit_{start,end} business. Signed-off-by: Sage Weil <sage@redhat.com>
Signed-off-by: Sage Weil <sage@redhat.com>
Signed-off-by: Sage Weil <sage@redhat.com>
Don't rely on the Allocator to do this for us (that is about to go away!). Signed-off-by: Sage Weil <sage@redhat.com>
Signed-off-by: Sage Weil <sage@redhat.com>
Signed-off-by: Sage Weil <sage@redhat.com>
This mimics, roughly, open(..., O_WRONLY|O_CREAT, ...) seek(...) if (len > 0) write(...) Signed-off-by: Sage Weil <sage@redhat.com>
ce35496
to
a411f58
Compare
No need for the allocator to coordinate with the kv commit cycle. Instead,
make it hte caller's responsibility to not release extents until their dereference
has been committed.