From 6a30b345aab9f5194989dfd81a2852e204a58785 Mon Sep 17 00:00:00 2001 From: Eliza Weisman Date: Fri, 8 May 2026 15:54:02 -0700 Subject: [PATCH] rt: 4 work-stealing passes rather than 2 --- tokio/src/runtime/scheduler/multi_thread/worker.rs | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tokio/src/runtime/scheduler/multi_thread/worker.rs b/tokio/src/runtime/scheduler/multi_thread/worker.rs index e7712d3de..3db8bf0f1 100644 --- a/tokio/src/runtime/scheduler/multi_thread/worker.rs +++ b/tokio/src/runtime/scheduler/multi_thread/worker.rs @@ -1139,12 +1139,13 @@ impl Core { // giving up? On the final pass we shall additionally attempt to steal // tasks from each worker's LIFO slot should the run queue be empty. // - // Two passes was chosen arbitrarily. The Go runtime makes four similar - // workstealing passes, but it also attempts to steal both timers and GC - // work as well as goroutines (tasks), so that's a bit different than - // our behavior. See: + // The Go runtime makes four similar work-stealing passes, and only attempts to steal from `runnext` (its name for a LIFO slot) on the final pass. See: // https://github.com/golang/go/blob/release-branch.go1.26/src/runtime/proc.go#L3828-L3895 - const PASSES: usize = 2; + // + // Empirically, 4 seems to result in better performance on the + // `rt_multi_thread` benchmarks than 2 passes, so we'll do the same + // thing Go does, I guess. + const PASSES: usize = 4; let num = worker.handle.shared.remotes.len(); for i in 1..=PASSES {