salad: reserve block before bps_tree_insert_first_elem#11857
Merged
sergepetrenko merged 1 commit intotarantool:masterfrom Oct 7, 2025
Merged
Conversation
0aa3f48 to
6baf87e
Compare
nshy
requested changes
Sep 26, 2025
6047faa to
42c9e5d
Compare
42c9e5d to
6bb2426
Compare
The commit 51c56d9 ("salad: reserve extents for matras_touch on BPS tree operations") already made the tree self-sufficient - reserved blocks in garbage and extents for `matras_touch` calls prior to insertion and deletion. However, it didn't account for the addition of the first element to the tree, which creates the root leaf - this could also trigger `matras_touch` in `bps_tree_garbage_pop`. However, it turns out there is no need to touch blocks before taking them out of the garbage. There is an invariant that blocks in the garbage are definitely not used by any read views. Although from the point of view of the matras, they require copying and could potentially have been needed by these read views. Let's just remove this `matras_touch` from `bps_tree_garbage_pop`. Also let's reserve a block in the garbage before calling `bps_tree_insert_first_elem` to bring the tree even closer to self-sufficiency. Closes tarantool#11788 NO_DOC=bugfix
6bb2426 to
bf4bc6a
Compare
nshy
approved these changes
Sep 29, 2025
maryiaLichko
approved these changes
Oct 2, 2025
Collaborator
|
Successfully created backport PR for |
Collaborator
|
Successfully created backport PR for |
Collaborator
|
Successfully created backport PR for |
Collaborator
Backport summary
|
mkostoevr
added a commit
to mkostoevr/tarantool
that referenced
this pull request
Oct 24, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf
blocks in commit 05f708ba6b17b1e7e9a269131139d98c9debcb59 ("salad:
reserve block before bps_vec_insert_first_elem") as the blocks are
not required to be preserved in views and can be used without CoW.
The problem is that in some circumstances this approach can lead to
a tricky problem: if we've created a block, CoW'ed another one and
then update values of the created one, the new block could've been
CoW'ed by the previous `matras_touch` (as the blocks are located in
extents of greater size than the blocks themselves). So following
updates in the created block gone into the view while the current
matras head had the old view's values remained.
The problem is that if we don't touch the garbage on block creation,
we need to make sure there's no any `matras_touch` between the block
creation and the last assignment of its field. Let's fix the only
place where the guarantee is not preserved: the leaf insert routine.
Removed the target leaf touch from the `bps_tree_process_insert_leaf`
by the way as it's not required cause the leaf is touched on lookup.
Follows-up tarantool#11857
Closes tarantool#11979
NO_DOC=bugfix
NO_CHANGELOG=was not released
mkostoevr
added a commit
to mkostoevr/tarantool
that referenced
this pull request
Oct 24, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. Let's fix the only place where the guarantee is not preserved: the leaf insert routine. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up tarantool#11857 Closes tarantool#11979 NO_DOC=bugfix NO_CHANGELOG=was not released
mkostoevr
added a commit
to mkostoevr/tarantool
that referenced
this pull request
Oct 24, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch poped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up tarantool#11857 Closes tarantool#11979 NO_DOC=bugfix NO_CHANGELOG=was not released
mkostoevr
added a commit
to mkostoevr/tarantool
that referenced
this pull request
Oct 24, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up tarantool#11857 Closes tarantool#11979 NO_DOC=bugfix NO_CHANGELOG=was not released
mkostoevr
added a commit
to mkostoevr/tarantool
that referenced
this pull request
Oct 28, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up tarantool#11857 Closes tarantool#11979 NO_DOC=bugfix NO_CHANGELOG=was not released
sergepetrenko
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released
github-actions bot
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released (cherry picked from commit 24cdd89)
github-actions bot
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released (cherry picked from commit 24cdd89)
github-actions bot
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released (cherry picked from commit 24cdd89)
sergepetrenko
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released (cherry picked from commit 24cdd89)
sergepetrenko
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released (cherry picked from commit 24cdd89)
sergepetrenko
pushed a commit
that referenced
this pull request
Oct 31, 2025
We've removed CoW'ing of garbage blocks for creating new inner/leaf blocks in commit 52b3d4b ("salad: reserve block before bps_tree_insert_first_elem") as the blocks are not required to be preserved in views and can be used without CoW. The problem is that in some circumstances this approach can lead to a tricky problem: if we've created a block, CoW'ed another one and then update values of the created one, the new block could've been CoW'ed by the previous `matras_touch` (as the blocks are located in extents of greater size than the blocks themselves). So following updates in the created block gone into the view while the current matras head had the old view's values remained. The problem is that if we don't touch the garbage on block creation, we need to make sure there's no any `matras_touch` between the block creation and the last assignment of its field. We could fix the only place where the guarantee is not preserved: the leaf insert routine, but let's keep the tree similar to the BPS vector and simply revert the change and touch popped garbage blocks too. Since now the garbage pop invokes CoW, we might need to reserve more memory for touches, as some new garbage blocks can be allocated on the `bps_vec_reserve_blocks`, but other ones can be existing in the vector previously, and, for these ones, we must reserve touches. Also, one more touch might be required if a new block allocated on reserve. Removed the target leaf touch from the `bps_tree_process_insert_leaf` by the way as it's not required cause the leaf is touched on lookup. Follows-up #11857 Closes #11979 NO_DOC=bugfix NO_CHANGELOG=was not released (cherry picked from commit 24cdd89)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
The commit 51c56d9 ("salad: reserve extents for matras_touch on BPS tree operations") already made the tree self-sufficient - reserved blocks in garbage and extents for
matras_touchcalls prior to insertion and deletion. However, it didn't account for the addition of the first element to the tree, which creates the root leaf - this could also triggermatras_touchinbps_tree_garbage_pop.However, it turns out there is no need to touch blocks before taking them out of the garbage. There is an invariant that blocks in the garbage are definitely not used by any read views. Although from the point of view of the matras, they require copying and could potentially have been needed by these read views. Let's just remove this
matras_touchfrombps_tree_garbage_pop. Also let's reserve a block in the garbage before callingbps_tree_insert_first_elemto bring the tree even closer to self-sufficiency.Closes #11788
NO_DOC=bugfix