* move `ExecuteTimings` from `runtime::bank` to `program_runtime::timings`
(cherry picked from commit 7d32909e17)
# Conflicts:
# core/Cargo.toml
# ledger/Cargo.toml
# programs/bpf/Cargo.lock
* Add execute metrics
(cherry picked from commit b25e4a200b)
* Add metrics for executor creation
(cherry picked from commit 848b6dfbdd)
* Add helper macro for `AddAssign`ing with saturating arithmetic
(cherry picked from commit deb9344e49)
* Use saturating_add_assign macro
(cherry picked from commit 72fc6096a0)
* Consolidate process instruction execution timings to own struct
(cherry picked from commit 390ef0fbcd)
Co-authored-by: Trent Nelson <trent@solana.com>
Co-authored-by: Carl Lin <carl@solana.com>
* get_signatures_for_address does not correctly account for result sets that span Blockstore and Bigtable.
This causes Bigtable to return `RowNotFound` until the new tx is uploaded.
Check that `before` exists in Bigtable, and if not, set it to `None` to return the full data set.
References #21442Closes#22110
* Differentiate between before sig not found and no newer signatures
* Dedupe bigtable results to account for potential upload race
Co-authored-by: Tyera Eulberg <tyera@solana.com>
(cherry picked from commit bac6821e19)
Co-authored-by: Omar Kilani <omar.kilani@gmail.com>
The indices for erasure coding shreds are tied to data shreds:
https://github.com/solana-labs/solana/blob/90f41fd9b/ledger/src/shred.rs#L921
However with the upcoming changes to erasure schema, there will be more
erasure coding shreds than data shreds and we can no longer infer coding
shreds indices from data shreds.
The commit adds constructs to track coding shreds indices explicitly.
(cherry picked from commit 65d59f4ef0)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
next-shred-index is already readily available from returned data shreds.
The commit simplifies the api for upcoming changes to erasure coding
schema which will require explicit tracking of indices for coding shreds
as well as data shreds.
(cherry picked from commit 89d66c3210)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* uses Option<Slot> for SlotMeta.parent_slot (#21808)
SlotMeta.parent_slot for the head of a detached chain of slots is
unknown and that is indicated by u64::MAX which lacks type-safety:
https://github.com/solana-labs/solana/blob/6c108c8fc/ledger/src/blockstore_meta.rs#L203-L205
The commit changes the type to Option<Slot>. Backward compatibility is
maintained by customizing serde serialize/deserialize implementations.
(cherry picked from commit 8d980f07ba)
# Conflicts:
# ledger-tool/src/main.rs
* removes backport merge conflicts
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
SlotMeta.last_index may be unknown and current code is using u64::MAX to
indicate that:
https://github.com/solana-labs/solana/blob/6c108c8fc/ledger/src/blockstore_meta.rs#L169-L174
This lacks type-safety and can introduce bugs if not always checked for
Several instances of slot_meta.last_index + 1 are also subject to
overflow.
This commit updates the type to Option<u64>. Backward compatibility is
maintained by customizing serde serialize/deserialize implementations.
(cherry picked from commit e08139f949)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
https://github.com/solana-labs/solana/pull/16646
removed first_coding_index since the field is currently redundant and
always equal to fec_set_index.
However, with upcoming changes to erasure coding schema, this will no
longer be the same as fec_set_index and so requires a separate field to
represent.
(cherry picked from commit 49ba09b333)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
https://github.com/solana-labs/solana/pull/17004
removed position field from coding-shred-header because as it stands the
field is redundant and unused.
However, with the upcoming changes to erasure coding schema this field
will no longer be redundant and needs to be populated.
(cherry picked from commit cd17f63d81)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
Allows the use of GPU acceleration in verifying the signatures in Entry's after deserialization in the replay stage
Co-authored-by: Stephen Akridge <sakridge@gmail.com>
Co-authored-by: Ryan Leung <ryan.leung@solana.com>
Problem
Blockstore currently removes erasure shreds if the data shreds are
successfully recovered on insert, which is an issue if we want to
serve coding shreds over repair.
Summary of Changes
This diff keeps all coding shreds even on successful recovery and
changes change the signature of prev_inserted_codes to immutable
reference to ensure its immunity.
Fixes#20968
