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

Jp/perf 2.9 2025013 #689

Merged
merged 39 commits into from
Jan 24, 2025
Merged

Conversation

JamesPiechota
Copy link
Collaborator

No description provided.

@JamesPiechota JamesPiechota changed the base branch from master to release/N.2.9.0-early-adopter January 14, 2025 21:10
@ldmberman ldmberman force-pushed the release/N.2.9.0-early-adopter branch from cd97224 to 324923a Compare January 15, 2025 14:39
@JamesPiechota JamesPiechota force-pushed the jp/perf-2.9-2025013 branch 4 times, most recently from 9906730 to 89d5b1f Compare January 17, 2025 23:16
@JamesPiechota JamesPiechota marked this pull request as ready for review January 17, 2025 23:16
ar_device_lock ensures that only one storage module on a device
is preparing entropy at a time, and ensures that no other storage modules
on that device are syncing data.
- entropy is now written in a separate thread from entropy generation
  this allows *some* parallelization since entropy generation is usually
  faster than storing. We now start generatng the next batch of entropy
  while the previous batch is being written
- slight optimization for ar_storage_module:get_all_packed. We now cache
  each module and its covered range once, rather than building it each time.
  Since this is part of a loop that gets called for each chunk stored
  (potentially thousands of times a seconds), it makes a measurable
  difference in performance.
- ensure only one thread writes all chunks in a given storage module. This
  avoid the disk thrash that used to occur when writing many different chunks
  concurrently.
- Only emit the add_range event for the ar_data_sync sync_record. This was the
  only event that was handled by any clients, however many more events were
  previously being emitted. Even the null-handling of the events was sometimes
  enough to impact performace.
@JamesPiechota JamesPiechota requested review from ldmberman and removed request for ldmberman January 21, 2025 21:02
Lev Berman and others added 13 commits January 23, 2025 18:30
1. When writing entropy to the overlap zone between storage modules
   sometimes entropy could be written over chunk data. Fix is not
   to write to neighboring storage modules and instead waste a bit
   of entropy. Wasted entropy is about 0.07% of all entropy generated
   per partition.
2. When repacking in place make sure we wait for entropy to be written
   whenever moving to a new slice index. This is primarily an issue
   during tests where there are only 3 chunks per sector, but could
   hypothetically be an issue in production.
3. Remove all code related to sub-chunk iteration since we don't need
   it and it may impact performance.
JamesPiechota and others added 2 commits January 24, 2025 15:42
this reduces the disk thrash that can occur when doing a cross-module
repack
@JamesPiechota JamesPiechota merged commit 174c73d into release/N.2.9.0-early-adopter Jan 24, 2025
72 checks passed
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.

1 participant