Separate CPU fairness from response-time promises

Begin with an idealized single CPU and two tasks that remain runnable for the entire observation interval. If they have equal weights and no other competitors, equal CPU service is a reasonable fairness target. If one task has three times the other's weight, the corresponding proportional target is three quarters versus one quarter. Weights describe relative allocation under competition; they are not reservations that create extra hardware capacity. When the lighter task sleeps, the heavier task may use otherwise idle service. When another competitor arrives, the denominator changes. A fair share therefore depends on the eligible competing set, not merely one task's configuration.

Linux normal scheduling includes details that prevent this arithmetic from being a universal prediction. CPU affinity restricts where a task may run, group scheduling distributes service through a hierarchy, and CPU quotas can throttle a group even when a thread remains eager to execute. Container CPU weight and maximum bandwidth describe different controls. A weight influences competition; a quota constrains total allowed consumption over its configured period. A task can have a large relative weight yet be periodically throttled by a small quota. Before diagnosing unfairness, identify its effective CPU set, scheduling policy, group hierarchy, and bandwidth restrictions, then ask which tasks actually competed.

Historical explanations of Linux's Completely Fair Scheduler often describe ordering tasks by virtual runtime. Modern kernel documentation describes the transition toward Earliest Eligible Virtual Deadline First, or EEVDF, in the normal scheduling implementation. EEVDF combines eligibility based on service lag with selection using virtual deadlines. Treat these names as version-sensitive implementation concepts rather than assuming every deployed machine follows the same pick-next rule. A virtual deadline used inside a fairness algorithm is not automatically an application deadline guarantee. When investigating a specific kernel, consult the matching source, configuration, and documentation rather than repeating a timeless claim about one tree or one selection heuristic.

There is likewise no single universal Linux timeslice that explains every policy and workload. SCHED_FIFO uses fixed-priority real-time semantics without round-robin expiration at equal priority; SCHED_RR adds round-robin rotation among peers. Normal policies serve other responsiveness and fairness goals. SCHED_DEADLINE uses runtime, deadline, and period parameters with admission and bandwidth mechanisms; accepting its parameters is not a substitute for validating the workload's execution demand and blocking behavior. Changing a thread into a more privileged policy can move delay onto unrelated work. Specify the required timing property first, then choose and test policy rather than using priority as an unexplained performance knob.

Two tasks can each obtain half a CPU-second over one second while experiencing very different response times. One could run in short interleaved bursts; another pattern could postpone useful service until near the interval's end. Their accumulated shares match, but an interactive request distinguishes them immediately. Conversely, a sleeping task cannot demand service for time during which it was not runnable merely by comparing lifetime totals. Measure runnable waiting intervals, wakeup-to-dispatch delay, completed work, and accumulated CPU service separately. Decide whether your objective is bounded latency, proportional throughput, or isolation under contention, because a single average CPU percentage cannot establish all three properties.

The queue lab exposes only the capacity side of this discussion. Its arrival rate and service rate move a fluid backlog, starting from four work units; they do not assign tasks to scheduling classes or implement EEVDF. Compare smaller and larger assumed CPU allocations through separate fixed-rate runs: arrival 2 with service 1 versus arrival 2 with service 3. Before each run, press Reset, re-set both rates, predict whether its initial four work units grow or drain, then press Play or Step. These runs do not model a live allocation change applied to an accumulated backlog. The M/M/1 residence-time expression is a separate stochastic idealization valid only below saturation with its stated assumptions. Neither curve proves that a real task will meet a deadline. To connect the illustration to deployment, reproduce a controlled workload, observe per-task scheduling events and group throttling, and compare the evidence against the timing property you actually need.