os/blueStore: In osd_tp_thread, call _txc_finalize_kv. #14709
Conversation
| @@ -7893,7 +7892,6 @@ void BlueStore::_kv_sync_thread() | |||
| } | |||
| for (auto txc : kv_submitting) { | |||
| assert(txc->state == TransContext::STATE_KV_QUEUED); | |||
| _txc_finalize_kv(txc, txc->t); | |||
There was a problem hiding this comment.
This has to happen in kv_sync_thread when using ExtentFreelistManager. For the bitmap one it could be moved. Perhaps we should just drop the extent-based implementation....
liewegas
changed the title
|
@ifed01 what do you think? |
|
When choosing between additional flag verification at different locations and eliminating extentfreelist I'd select the second. |
|
extentfreelist has to be ordered at commit time since each update is a
read/modify/write of the kv state
|
|
So we can remove extent allocator for bluestore. Still keep for bluefs. Is it ok? |
|
bluefs doesn't use the freelistmanagers at all, so we can remove it
entirely, i think!
|
|
Sorry, I missed the freelistmanger && allocator. I'd like to send another PR to remove extentlistmanager. |
majianpeng
force-pushed
the
luestore-txc-finalize-kv
branch
from
65de6d0
to
bdf340f
Compare
|
update . please review. |
To reduce overhead of _kv_sync_thread, make _txc_finalize_kv do in_osd_tp_thread. Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
|
We could take this one step further and combine finalize_kv and write_nodes. This looks good though! |
|
There is still another call for txc_finalize_kv from kv_sync_thread for deferred traansactions hence not sure if we can merge the funcs |
|
I think it is still a relic? It looks like txc_finalize_kv is just adding
the freelist update to the transaction, and that is all known at the end
of prepare_transaction.
|
|
As far as I understand it's there for kraken WAL compatibility. And we should update freelist here as well. Hence we can eliminate this call only if we don't bother that compatibility any more. |
|
oh right! we need to keep that.
|
|
BTW it looks like there is another potential issue with that in Kraken - one might call txc_finalize_kv twice for the same txc. Probably we need to clear txc's allocated/released containers in txc_finalize_kv. At least for Kraken |
|
(we can ditch it right after luminous)
|
|
IIRC that's what happens in kraken... in queue_transaction it does
// move releases to after wal
txc->wal_txn->released.swap(txc->released);
and in wal_finish it does
// move released back to txc
txc->wal_txn->released.swap(txc->released);
assert(txc->wal_txn->released.empty());
|
To reduce overhead of _kv_sync_thread, make _txc_finalize_kv do
in_osd_tp_thread.
Signed-off-by: Jianpeng Ma jianpeng.ma@intel.com