Tokio LIFO slot latency bound: missing configuration for tail-latency control

Scheduler behavior under sustained concurrency

Tokio's per-worker LIFO slot optimizes throughput by keeping recently yielded tasks on the same worker, reducing cache misses for bursty workloads. Under sustained high concurrency, however, tasks that repeatedly yield can monopolize the slot, starving other ready tasks that remain in the global FIFO queue. This creates unbounded tail latency for the starved tasks with no documented upper bound.

Missing configurability

The LIFO slot is an implementation detail, not a configurable policy. No public API exists to disable it, set a maximum residency, or enforce round-robin fairness across tasks on the same worker. Documentation acknowledges the optimization but does not specify latency bounds, starvation freedom, or conditions under which a task may be deferred indefinitely while new work arrives.

Workload constraints

Applications with SLO-bound tail latency (real-time trading, latency-sensitive services) cannot rely on the scheduler for predictability. Increasing worker count reduces but does not eliminate the effect, since cross-worker stealing uses a FIFO queue while the per-worker LIFO behavior persists. Blocking operations moved to spawn_blocking bypass the slot but add thread-pool latency unsuitable for high-frequency async tasks.

What mechanism could expose a configurable residency limit or fairness policy for the LIFO slot without sacrificing the throughput benefits for bursty workloads? Is there a viable path to standardize a latency-bound scheduling interface across Rust async runtimes?