Account data direct mapping #28053
Merged
Account data direct mapping #28053
Conversation
This file contains 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
alessandrod
force-pushed
the
direct_mapping
branch
7 times, most recently
from
b62527c
to
7ad11d8
Compare
alessandrod
force-pushed
the
direct_mapping
branch
6 times, most recently
from
afd32c6
to
3eef8b8
Compare
alessandrod
force-pushed
the
direct_mapping
branch
from
80bcda9
to
6543678
Compare
alessandrod
force-pushed
the
direct_mapping
branch
from
6543678
to
36eefbc
Compare
alessandrod
force-pushed
the
direct_mapping
branch
2 times, most recently
from
d6635f2
to
8c4d0f2
Compare
alessandrod
force-pushed
the
direct_mapping
branch
3 times, most recently
from
eda8806
to
da79024
Compare
Lichtso
reviewed
Nov 30, 2022
Lichtso
reviewed
Dec 13, 2022
…en direct_mapping is on
…ough Introduce a better way to ensure that account capacity never goes below what might be mapped in memory regions.
…::spare_data_capacity_mut() Before we were using BorrowedAccount::get_data_mut() to get the base pointer to the account data, then we were slicing the spare capacity from it. Calling get_data_mut() doesn't work if an account has been closed tho, since the current program doesn't own the account anymore and therefore get_data_mut() errors out.
…unt region violations
Add a test that after a realloc does a large write that spans the original account length and the realloc area. This ensures that memory mapping works correctly across the boundary.
…n and off By default test banks test with all features on. This ensures we keep testing the existing code until the new feature is enabled.
Split the actual memcmp code in a separate function. Remove check indexing the slices since the slices are guaranteed to have the correct length by construction.
Use slice::fill, which is effectively memset.
… memory With direct mapping enabled, accounts can now span multiple memory regions.
Simplify the logic to update a caller's memory region when a callee causes an account data pointer to change (eg during CoW)
When starting at u64::MAX, the chunk iterator would always return the empty sequence (None on the first next()) call, instead of returning a memory access violation. Use checked instead of saturating arithmetic to detect the condition and error out. This commit also adds more tests around boundary conditions.
With direct mapping on, invalid writes are caught early meaning the tuner would fail on the first store and not consume the whole budget like the benchmark expects.
alessandrod
force-pushed
the
direct_mapping
branch
from
8ce9624
to
9b4cbb3
Compare
Lichtso
approved these changes
Apr 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR introduces the
bpf_account_data_direct_mappingfeature. When enabled, account data is directly mapped into vm memory at vm setup time. This removes the need to have large copies during transaction execution, going in and out of the vm at each instruction/CPI boundary.The only data copy left now is when an account is first mapped as writable during a transaction. That copy is unavoidable at the moment since accounts are cached in memory and written back only every N slots. I'm planning to try and remove that copy in a separate PR.
Feature gate issue: #29708