Skip to content

Normalize burst handling for unlimited bandwidth limits#1192

Merged
oferchen merged 1 commit into
masterfrom
implement-missing-components-for-oc-rsync
Oct 27, 2025
Merged

Normalize burst handling for unlimited bandwidth limits#1192
oferchen merged 1 commit into
masterfrom
implement-missing-components-for-oc-rsync

Conversation

@oferchen
Copy link
Copy Markdown
Owner

Summary

  • ensure BandwidthLimitComponents::new discards burst hints when the limit is unlimited so the helper mirrors upstream semantics
  • add a regression test that exercises the invariant for unlimited bandwidth configurations

Testing

  • cargo test -p rsync-bandwidth

https://chatgpt.com/codex/tasks/task_e_68feb929c0f883239435fad25fb3d8c1

@oferchen oferchen merged commit cddcc16 into master Oct 27, 2025
@oferchen oferchen deleted the implement-missing-components-for-oc-rsync branch October 27, 2025 00:19
oferchen added a commit that referenced this pull request May 5, 2026
…nalysis (#1192)

Static analysis of every Arc<Mutex<Vec<...>>> remaining in the workspace,
focused on the parallel stat hot path. Confirms parallel stat does not
allocate any shared mutex-guarded accumulator: map_blocking delegates to
rayon's into_par_iter().map().collect() with per-task buffers internal
to rayon. Three production sites remain (SSH stderr drain x2, drain_parallel
shards), only the third is on a rayon hot path and is sharded already.

Cites the just-merged drain-side audit (PR #3699) for the drain-shards
analysis, scopes #1192 to runtime profiling needed for closure, and lists
mitigations to evaluate only if profiling surfaces a residual Mutex<Vec>.
oferchen added a commit that referenced this pull request May 5, 2026
…nalysis (#1192) (#3727)

Static analysis of every Arc<Mutex<Vec<...>>> remaining in the workspace,
focused on the parallel stat hot path. Confirms parallel stat does not
allocate any shared mutex-guarded accumulator: map_blocking delegates to
rayon's into_par_iter().map().collect() with per-task buffers internal
to rayon. Three production sites remain (SSH stderr drain x2, drain_parallel
shards), only the third is on a rayon hot path and is sharded already.

Cites the just-merged drain-side audit (PR #3699) for the drain-shards
analysis, scopes #1192 to runtime profiling needed for closure, and lists
mitigations to evaluate only if profiling surfaces a residual Mutex<Vec>.
oferchen added a commit that referenced this pull request May 7, 2026
Static audit of every Arc<Mutex<Vec<...>>> reachable from the parallel
stat and drain_parallel hot paths in transfer/engine/flist, with the
measurement plan and decision criteria for any replacement work.
oferchen added a commit that referenced this pull request May 16, 2026
Add criterion microbench under crates/transfer/benches profiling four
result-collection strategies (shared Arc<Mutex<Vec>>, sharded
Mutex<Vec> by rayon worker id, crossbeam SegQueue, crossbeam unbounded
channel) over 100K items at 1/4/8/16 rayon worker counts. Throughput
is reported in elements/sec so the bench output names the worker
count at which the single shared mutex saturates.

The shipping parallel-stat path in crates/transfer/src/parallel_io.rs
does not use Arc<Mutex<Vec>>; it collects via
into_par_iter().map(f).collect(), which delegates to rayon's lock-free
reducer. Document this in docs/audits/parallel-stat-collection.md and
keep the microbench as the baseline against which any future PR that
proposes reintroducing a shared mutex on this path must be measured
(tracked under #1192, #1271, #1297, #1370, #1682).
oferchen added a commit that referenced this pull request May 16, 2026
… (#4170)

* chore(bench): add parallel-stat collector contention microbench

Add criterion microbench under crates/transfer/benches profiling four
result-collection strategies (shared Arc<Mutex<Vec>>, sharded
Mutex<Vec> by rayon worker id, crossbeam SegQueue, crossbeam unbounded
channel) over 100K items at 1/4/8/16 rayon worker counts. Throughput
is reported in elements/sec so the bench output names the worker
count at which the single shared mutex saturates.

The shipping parallel-stat path in crates/transfer/src/parallel_io.rs
does not use Arc<Mutex<Vec>>; it collects via
into_par_iter().map(f).collect(), which delegates to rayon's lock-free
reducer. Document this in docs/audits/parallel-stat-collection.md and
keep the microbench as the baseline against which any future PR that
proposes reintroducing a shared mutex on this path must be measured
(tracked under #1192, #1271, #1297, #1370, #1682).

* chore: sync Cargo.lock after dev-dep addition
oferchen added a commit that referenced this pull request May 18, 2026
…nalysis (#1192) (#3727)

Static analysis of every Arc<Mutex<Vec<...>>> remaining in the workspace,
focused on the parallel stat hot path. Confirms parallel stat does not
allocate any shared mutex-guarded accumulator: map_blocking delegates to
rayon's into_par_iter().map().collect() with per-task buffers internal
to rayon. Three production sites remain (SSH stderr drain x2, drain_parallel
shards), only the third is on a rayon hot path and is sharded already.

Cites the just-merged drain-side audit (PR #3699) for the drain-shards
analysis, scopes #1192 to runtime profiling needed for closure, and lists
mitigations to evaluate only if profiling surfaces a residual Mutex<Vec>.
oferchen added a commit that referenced this pull request May 18, 2026
Static audit of every Arc<Mutex<Vec<...>>> reachable from the parallel
stat and drain_parallel hot paths in transfer/engine/flist, with the
measurement plan and decision criteria for any replacement work.
oferchen added a commit that referenced this pull request May 18, 2026
… (#4170)

* chore(bench): add parallel-stat collector contention microbench

Add criterion microbench under crates/transfer/benches profiling four
result-collection strategies (shared Arc<Mutex<Vec>>, sharded
Mutex<Vec> by rayon worker id, crossbeam SegQueue, crossbeam unbounded
channel) over 100K items at 1/4/8/16 rayon worker counts. Throughput
is reported in elements/sec so the bench output names the worker
count at which the single shared mutex saturates.

The shipping parallel-stat path in crates/transfer/src/parallel_io.rs
does not use Arc<Mutex<Vec>>; it collects via
into_par_iter().map(f).collect(), which delegates to rayon's lock-free
reducer. Document this in docs/audits/parallel-stat-collection.md and
keep the microbench as the baseline against which any future PR that
proposes reintroducing a shared mutex on this path must be measured
(tracked under #1192, #1271, #1297, #1370, #1682).

* chore: sync Cargo.lock after dev-dep addition
oferchen added a commit that referenced this pull request May 18, 2026
… (#4170)

* chore(bench): add parallel-stat collector contention microbench

Add criterion microbench under crates/transfer/benches profiling four
result-collection strategies (shared Arc<Mutex<Vec>>, sharded
Mutex<Vec> by rayon worker id, crossbeam SegQueue, crossbeam unbounded
channel) over 100K items at 1/4/8/16 rayon worker counts. Throughput
is reported in elements/sec so the bench output names the worker
count at which the single shared mutex saturates.

The shipping parallel-stat path in crates/transfer/src/parallel_io.rs
does not use Arc<Mutex<Vec>>; it collects via
into_par_iter().map(f).collect(), which delegates to rayon's lock-free
reducer. Document this in docs/audits/parallel-stat-collection.md and
keep the microbench as the baseline against which any future PR that
proposes reintroducing a shared mutex on this path must be measured
(tracked under #1192, #1271, #1297, #1370, #1682).

* chore: sync Cargo.lock after dev-dep addition
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant