EEVDF scheduling introduces latency spikes for interactive workloads

Direct answer

There is no standard runtime sysctl or guaranteed boot parameter that toggles EEVDF versus CFS in stock mainline Linux. Kernel 6.6 and later use EEVDF by default; earlier mainline kernels use CFS. Selecting CFS on a 6.6+ kernel generally requires an older kernel, a distro-specific build, or a boot option your kernel exposes—none of which can be assumed without checking your build.

How EEVDF calculates deadlines

EEVDF orders tasks by virtual deadline rather than by CFS min_vruntime alone. For each eligible task, normalized virtual time advances by the executed delta scaled by NICE_0_LOAD divided by the task weight. A task becomes eligible at the greater of the scheduler’s virtual clock and its wake or release time. Its deadline is approximately that eligible time plus the current burst service divided by weight; the earliest eligible deadline runs first. Higher priority (lower nice) means larger weight, slower virtual-time advance per CPU unit, and usually a nearer deadline for the same burst, but exact placement after sleep is version-sensitive and should not be hard-coded.

Likely explanation versus confirmed facts

Confirmed: mainline Linux switched to EEVDF by default at 6.6; CFS remains the default before that. /proc/sched_debug, /proc/<pid>/sched, and perf sched latency can expose runqueue and per-entity accounting when CONFIG_SCHED_DEBUG is enabled.

Likely explanation, not confirmed: an interactive task can spike in latency under EEVDF when another runnable task holds an earlier virtual deadline, or when wakeup eligibility does not make the waking task the earliest deadline. CFS may preempt sleepers sooner in some patterns. This remains a hypothesis until wakeup-to-run traces correlate the spike with a non-selected earlier-deadline task.

Verification steps for this case

1. Confirm kernel and scheduler: uname -r and inspect the header of /proc/sched_debug (may require root and CONFIG_SCHED_DEBUG).
2. Record baseline behavior: perf sched record -a sleep N then perf sched latency, comparing max and average wakeup delay on the same workload and CPU set.
3. Correlate wakeups to scheduling decisions: trace-cmd record -e sched:sched_wakeup -e sched:sched_wakeup_new -e sched:sched_switch -e sched:sched_stat_wait -e sched:sched_stat_sleep -a, then trace-cmd report. Measure the delay from a sched_wakeup or sched_wakeup_new event to the sched_switch that selects the same pid on the same CPU.
4. Inspect per-task accounting comparatively: cat /proc/<pid>/sched and /proc/sched_debug across runs. Treat field names and values as build-specific, not absolute proof.

Missing diagnostic detail

Whether the spike is wakeup-to-first-run delay on the same CPU versus runqueue delay after selection, and whether the affected task is SCHED_OTHER/nice versus real-time or CPU-isolated. That detail changes whether you tune nice, cpuset, or isolation, or whether you look elsewhere entirely.

Assumptions and uncertainty

• Assumes stock mainline or a distribution kernel close to mainline behavior; vendor patches may add toggles not covered here.
• EEVDF deadline constants and /proc field semantics differ by kernel version and config; do not use them in automation without verifying your build.
• EEVDF causality is not proven by latency alone; trace correlation is required before changing the production scheduler.

This draft requires verification against your kernel build before any production scheduler change.