Evaluating Linux Schedulers

We compared Linux's newer Earliest Eligible Virtual Deadline First scheduler with the Completely Fair Scheduler on equivalent 40-logical-CPU CloudLab bare-metal nodes. Rather than relying on one microbenchmark, we varied scheduler, contention, task priority, and EEVDF time-slice settings across repeated experiments.

• Ran EEVDF on Linux 6.17.10 and CFS on Linux 6.1.158 with otherwise equivalent Ubuntu 24.04 configurations.
• Disabled CPU-frequency scaling and saturated the available cores to keep contention reproducible.
• Compared equal-priority workloads with explicitly differentiated nice values of -15 and +15.
• Varied EEVDF's requested slice through sched_setattr() to isolate the effect of execution fragmentation.

The evaluation paired latency-sensitive foreground applications with sustained CPU pressure, then measured outcomes users and operators actually experience: frame drops, HTTP latency, Redis throughput, wakeup-tail latency, and compression throughput.

• Ran MPV against stress-ng and measured dropped frames across increasing worker counts.
• Benchmarked Redis GET and SET throughput and a Python HTTP server under stress-ng contention.
• Paired schbench with 7-Zip to compare wakeup-latency distributions against compute throughput.
• Evaluated both unconfigured equal-priority behavior and explicitly prioritized production-style configurations.

Application timing showed which scheduler won a workload; eBPF instrumentation explained why. We traced virtual lag, wakeups, context switches, and preemption frequency to distinguish prompt scheduling from the length and continuity of the execution a task received.

• Attached a kretprobe to pick_next_task_fair to record EEVDF virtual lag at each dispatch.
• Traced sched_wakeup and sched_switch events to measure preemption and execution fragmentation.
• Connected lower run-queue delay under EEVDF with shorter, more fragmented execution bursts.
• Connected CFS's weaker tail guarantees with longer uninterrupted intervals and warmer caches.

Neither scheduler dominates every workload. EEVDF's bounded-fairness model protects worst-case responsiveness, while CFS can favor state-heavy or throughput-oriented applications by allowing longer contiguous runs. Explicit priority configuration also removes much of EEVDF's advantage for Redis.

• At 512 schbench threads, EEVDF delivered 4–6× lower 99.9th-percentile wakeup latency than CFS.
• Under equal priorities and high contention, EEVDF improved Redis GET throughput by up to 65% and SET throughput by up to 57%.
• With differentiated priorities, CFS achieved 13–59% lower HTTP latency by reducing execution fragmentation.
• CFS sustained 10–15% more 7-Zip throughput at 256–512 threads, exposing the latency-versus-contiguity trade-off.