Skip to content
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

runtime: runtime scoped spad that replaces wksp and scratch allocations #4028

Merged
merged 1 commit into from
Feb 3, 2025

Conversation

ibhatt-jumptrading
Copy link
Contributor

@ibhatt-jumptrading ibhatt-jumptrading commented Jan 27, 2025

Get rid of wksp and scratch allocations. Starting to remove the use of valloc in the runtime. Adding runtime scoped spad.

DOES NOT:

  1. Remove scratch outside of runtime hot path + in blockstore/gossip/repair
  2. Hasn't changed types to get rid of valloc completely
  3. Need to add caller safety check before allocs everywhere

@ibhatt-jumptrading ibhatt-jumptrading force-pushed the runtime_spad branch 2 times, most recently from a747fa2 to 64df671 Compare January 28, 2025 23:39
@ibhatt-jumptrading ibhatt-jumptrading marked this pull request as ready for review January 29, 2025 15:33
if( FD_UNLIKELY( sz>fd_spad_alloc_max( self->spad, FD_SPAD_ALIGN ) ) ) {
self->failed=1;
return NULL;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a WARNING log here

@ibhatt-jumptrading ibhatt-jumptrading force-pushed the runtime_spad branch 2 times, most recently from b7c5939 to 7a200b0 Compare January 31, 2025 20:41
@@ -736,172 +727,228 @@ typedef struct accounts_hash accounts_hash_t;
#define MAP_T accounts_hash_t
#include "../../util/tmpl/fd_map_dynamic.c"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes here are to support preallocating the buffers so we don't need to dynamically resize while we populate the buffers

/* FIXME: Define a bound for the size of the spad. It likely needs to be
larger than this. */
uchar * spad_mem_cur = spad_mem;
ctx->spad = fd_spad_join( fd_spad_new( spad_mem_cur, 1<<30 /* 1 GiB */ ) );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we make 1<<30 a macro (also optionally with a comment explaining why we chose this)? so we don't have this duplicated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

src/app/fdctl/run/tiles/fd_replay.c Outdated Show resolved Hide resolved
Comment on lines 1219 to 1230
FD_SPAD_FRAME_BEGIN( ctx->runtime_spad ) {
fd_txn_p_t * txn = (fd_txn_p_t *)fd_chunk_to_laddr( ctx->sender_out_mem, ctx->sender_out_chunk );
fd_tower_to_vote_txn( ctx->tower, ctx->root, vote_bank_hash, vote_block_hash, ctx->validator_identity, ctx->vote_authority, ctx->vote_acc, txn );
} FD_SCRATCH_SCOPE_END;
fd_tower_to_vote_txn( ctx->tower,
ctx->root,
vote_bank_hash,
vote_block_hash,
ctx->validator_identity,
ctx->vote_authority,
ctx->vote_acc,
txn,
ctx->runtime_spad );
} FD_SPAD_FRAME_END;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it might be clearer to move the spad frame setup/teardown inside fd_tower_to_vote_txn, as it's only used by this function. it's only ok to do the setup/teardown here because the allocation is thrown away inside fd_tower_to_vote_txn, so co-locating the logic makes it easier for the reader to understand the lifetime of the allocated memory.

src/flamenco/runtime/fd_runtime.c Show resolved Hide resolved
/* In order to correctly handle the lifetimes of allocations for partitioned
epoch rewards, we will push a spad frame when rewards partitioning starts.
We will only pop this frame when all of the rewards for the epoch have
been calculated. As a note, this is technically not the most optimal use
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
been calculated. As a note, this is technically not the most optimal use
been distributed. As a note, this is technically not the most optimal use

there should only be 1 or 2 frames that are on the stack. The first frame
will hold memory for the slot/epoch context. The potential second frame
will only exist while rewards are being distributed (around the start of
an epoch). We pop a frame when rewards are done being calculated */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
an epoch). We pop a frame when rewards are done being calculated */
an epoch). We pop a frame when rewards are done being distributed. */

topointon-jump
topointon-jump previously approved these changes Feb 3, 2025
Copy link
Contributor

@topointon-jump topointon-jump left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome

@ibhatt-jumptrading ibhatt-jumptrading changed the title runtime: runtime scoped spad that replaces wksp and scratch allocations [WIP] runtime: runtime scoped spad that replaces wksp and scratch allocations Feb 3, 2025
@ibhatt-jumptrading ibhatt-jumptrading added this pull request to the merge queue Feb 3, 2025
Merged via the queue into main with commit 5523adb Feb 3, 2025
11 checks passed
@ibhatt-jumptrading ibhatt-jumptrading deleted the runtime_spad branch February 3, 2025 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants