How does Linux actually schedule — CFS (and EEVDF)? What are nice values and cgroup weights really doing?

🎤 Say this first

CFS (Completely Fair Scheduler) drops fixed time slices and priorities-as-queues for one idea: track each task's vruntime (CPU time weighted by priority) and always run the task with the smallest vruntime — kept in a red-black tree, so picking is O(log n). 'Fairness' means equal weighted CPU shares over time; nice values change the weight (each nice step ≈ 1.25× CPU share), and cgroup CPU weights apply the same math to groups of tasks (this is what container CPU requests become). Since kernel 6.6, EEVDF refines CFS by adding explicit latency-deadline math, fixing CFS's fuzzy latency story.

The full picture

Why vruntime is elegant: I/O-bound tasks accumulate little vruntime while blocked → on wake they're far 'behind' → scheduled promptly. Interactivity falls out of the accounting — no heuristics about what's 'interactive'.
The weight math: vruntime advances at rate actual_time × (base_weight / task_weight) — high-weight tasks age slower, earning more CPU. Nice −5 vs 0 ≈ 3× share; cgroup cpu.weight does the same between containers.
Group fairness: CFS is hierarchical — first fairness between cgroups, then between tasks within one. A pod with 10 threads doesn't get 10× the CPU of a pod with 1.
EEVDF in one line: same weighted fairness, plus per-task virtual deadlines so latency-sensitive tasks get scheduled soon, not just eventually — replacing a pile of CFS wakeup heuristics.

⚠️ Common pitfall:Don't confuse weights (proportional shares, work-conserving — spare CPU is free) with quotas (hard caps). cpu.weight/requests only matter under contention; cpu.max/limits throttle even on an idle machine. This distinction is the next question — and most real-world 'K8s CPU mysteries'.

🎤 Say this first

The full picture

🔄 Likely follow-up questions