experiment: enable tokio eager driver handoff (3.7.0 follow-up)#230
Open
vadv wants to merge 2 commits intofeature/3.7.0-rust-tokio-editionfrom
Open
experiment: enable tokio eager driver handoff (3.7.0 follow-up)#230vadv wants to merge 2 commits intofeature/3.7.0-rust-tokio-editionfrom
vadv wants to merge 2 commits intofeature/3.7.0-rust-tokio-editionfrom
Conversation
added 2 commits
April 30, 2026 16:16
A worker holding the I/O / time driver while polling a long task can stall socket readiness on other workers. Tokio 1.52 added an opt-in eager handoff on the multi-threaded runtime that wakes a previously parked worker before polling and lets it own the driver. We turn it on under tokio_unstable to see whether p99/p999 latency improves under heavy concurrency. Pure experiment branched off feature/3.7.0-rust-tokio-edition. The decision to keep, tune, or revert depends on the Ubicloud benchmark vs. the 3.7.0 baseline.
Both pkg/rpm/pg-doorman.spec and debian/rules regenerate .cargo/config.toml to point at vendored sources before cargo build, which silently overwrites the rustflags entry committed for this experiment. As a result COPR and Launchpad builds failed to find Builder::enable_eager_driver_handoff. Re-deliver the cfg via RUSTFLAGS in both build scripts so the unstable API is available regardless of how the project's .cargo/config.toml is rewritten. Local cargo, Dockerfile and Ubicloud bench are unaffected — they pick up the shipped .cargo/config.toml as-is.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Goal
Measure whether Tokio 1.52's opt-in
Builder::enable_eager_driver_handoff(#8010) reduces p99/p999 latency for pg_doorman under heavy concurrency.What this branch does
Branched off
feature/3.7.0-rust-tokio-edition(PR #229). On top of the 3.7.0 base it:.cargo/config.tomlwith--cfg tokio_unstable(required by the API)..enable_eager_driver_handoff()on the multi-thread runtime insrc/app/server.rs.That is the entire diff (3 lines added across 2 files).
What we are testing
The mechanism: a worker which is about to poll a task and was previously parked on the I/O / time driver wakes another worker first and hands the driver off, so the notified worker can take ownership before this one starts polling. This avoids a pathology where one worker holds the driver through a long poll and blocks socket-readiness wakeups for tasks running on the others.
For a TCP-heavy connection pooler like pg_doorman this is the most directly applicable change in tokio 1.49–1.52 (vectored writes #7871 require migrating off
write_all; shardedspawn_blocking#7757 was reverted in 1.52.1).Validation plan
standard-30,bench_duration=30s,doorman_workers=auto,pgbench_jobs=4).tokio_unstable.Risk note
tokio_unstableis explicitly opt-in; the API may change or be removed in minor releases. Sister change in the same release window — shardedspawn_blocking(#7757) — was added in 1.52.0 and reverted in 1.52.1 due to a hang regression (#8056). Treat as experiment.Do not merge before #229.