Skip to content

docs(design): sharded BufferPool layout for high thread counts#3645

Merged
oferchen merged 1 commit into
masterfrom
docs/buffer-pool-sharding-design-1295
May 5, 2026
Merged

docs(design): sharded BufferPool layout for high thread counts#3645
oferchen merged 1 commit into
masterfrom
docs/buffer-pool-sharding-design-1295

Conversation

@oferchen
Copy link
Copy Markdown
Owner

@oferchen oferchen commented May 5, 2026

Summary

Design note for #1295 covering the current two-level BufferPool, a contention hypothesis at 32+ threads, three sharding approaches, and the recommended shard-then-fallback layout activated at 16+ rayon workers.

Key sections

  • Current state grounded in crates/engine/src/local_copy/buffer_pool/ line citations (pool.rs, thread_local_cache.rs, pressure.rs, allocator.rs).
  • Contention hypothesis: cache-line ping-pong on crossbeam_queue::ArrayQueue head/tail cursors at high producer/consumer asymmetry.
  • Three approaches considered: per-thread shard, per-CPU shard, two-level shard-then-fallback. Approach C selected.
  • Recommended design: shard count num_cpus * 2 clamped 4..64, shard capacity small, global fallback retains the existing soft-cap admission protocol.
  • Activation gated at rayon::current_num_threads() >= 16. Decision is frozen at construction.
  • Memory cost table, API impact (BufferAllocator unchanged), telemetry additions, risks, and the follow-up benchmark workloads bound to Handle extended ASCII whitespace in remote shell parser #1297.

Wire-compat

Zero impact. The buffer pool is internal to local-copy and delta-transfer paths; it does not appear in any wire format, capability string, or persisted state.

Test plan

  • Reviewers confirm citations resolve to current crates/engine/src/local_copy/buffer_pool/ source.
  • Reviewers agree on the 16-thread activation threshold and num_cpus * 2 shard count.
  • Implementation and benchmark TODOs (Handle extended ASCII whitespace in remote shell parser #1297) tracked separately; this PR is documentation-only.

Design note for #1295 covering current two-level pool, contention
hypothesis at 32+ threads, three sharding approaches, and the
recommended shard-then-fallback layout. Activation gated at 16+
rayon workers; trait surface and wire protocol unchanged.
@github-actions github-actions Bot added the documentation Improvements or additions to documentation label May 5, 2026
@oferchen oferchen merged commit 904735d into master May 5, 2026
8 checks passed
@oferchen oferchen deleted the docs/buffer-pool-sharding-design-1295 branch May 5, 2026 09:37
oferchen added a commit that referenced this pull request May 5, 2026
…3652)

Cross-cutting follow-up to PRs #3645 (buffer pool sharding) and
#3649 (daemon async accept). Both designs default to num_cpus * 2
which underutilizes I/O-bound workloads and oversubscribes
CPU-bound ones. This note specifies a feedback-driven adaptive
sizer with a PI-controller in the [60%, 85%] utilization band,
hard bounds [max(2, n/2), n*4], 5 s grow / 30 s shrink cadence,
and a daemon config knob "transfer-worker-threads = adaptive |
<int>" plus an OC_RSYNC_ADAPTIVE_THREADS env-var disable for the
first release. Zero wire-protocol impact.
oferchen added a commit that referenced this pull request May 18, 2026
Design note for #1295 covering current two-level pool, contention
hypothesis at 32+ threads, three sharding approaches, and the
recommended shard-then-fallback layout. Activation gated at 16+
rayon workers; trait surface and wire protocol unchanged.
oferchen added a commit that referenced this pull request May 18, 2026
…3652)

Cross-cutting follow-up to PRs #3645 (buffer pool sharding) and
#3649 (daemon async accept). Both designs default to num_cpus * 2
which underutilizes I/O-bound workloads and oversubscribes
CPU-bound ones. This note specifies a feedback-driven adaptive
sizer with a PI-controller in the [60%, 85%] utilization band,
hard bounds [max(2, n/2), n*4], 5 s grow / 30 s shrink cadence,
and a daemon config knob "transfer-worker-threads = adaptive |
<int>" plus an OC_RSYNC_ADAPTIVE_THREADS env-var disable for the
first release. Zero wire-protocol impact.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant