CPU fairness: distinguish weights, quotas, and placement

For ordinary fair-class scheduling, cpu.weight expresses relative weight among competing sibling cgroups, subject to the hierarchy and the actual runnable workload. An idealized division of a fully busy parent’s capacity is proportional to the active weights. This is a useful budgeting model, not a promise that every millisecond follows the same ratio. Runnable-thread counts, affinity, scheduling granularity, ancestor restrictions, and other scheduling classes can alter what a short observation sees. Measure CPU time over an appropriate interval and inspect the actual parent topology.

Weights are work-conserving: an idle sibling does not usually retain an unused time reservation that everyone else must leave untouched. If one tenant sleeps, another may consume more of the available parent capacity, subject to other restrictions. This borrowing improves utilization but also means that an observed solo rate is not a guaranteed shared rate. Compare tenants under controlled simultaneous demand. Do not tune a weight from a quiet cluster experiment and then call the resulting solo latency an entitlement under saturation.

The cpu.max quota and period bound aggregate fair-class CPU execution within the relevant bandwidth-control semantics. Multiple threads can consume that aggregate budget concurrently, leaving later work throttled until replenishment. A quota equivalent to one CPU can therefore coexist with bursts on several CPUs; it does not identify one permanently assigned core. An ancestor can impose a tighter effective restriction than the child’s own setting. Inspect throttling statistics and effective hierarchy rather than reading one leaf configuration in isolation.

Placement controls constrain eligible CPUs, but eligible CPUs can still have shared execution resources. Logical siblings may share a physical core, and different cores may share last-level cache, memory bandwidth, power, or thermal limits. Reserving a CPU set therefore requires a precise claim about exclusivity, sibling placement, and host work. For a latency-sensitive decoder, compare run-queue delay and throttling alongside application timings. A low average utilization graph cannot exclude brief exhaustion of the quota that repeatedly delays the critical path.

Hold the victim’s request mix, token lengths, batching, and concurrency fixed while adding a CPU aggressor. Record offered load, admitted work, CPU time, throttled duration, run-queue delay, and deadline success. An aggressor that changes memory bandwidth as well as CPU demand tests a broader boundary than a compute-only loop. Repeat across relevant placement arrangements and distinguish a tenant’s configured ceiling from the useful work it actually receives. A result should identify which shared mechanism explains the degradation rather than attribute every slowdown to scheduling weights.

The queue lab illustrates an average service imbalance without modeling a Linux scheduler. Reset, explicitly set arrival two and service three, predict drainage of the initial four items, then Play or Step. In a separate run Reset and explicitly set arrival four and service three before predicting growth. Editing rates retains elapsed time and recomputes from the initial backlog, so it is not a live throttling experiment. The lab has no runnable threads, cgroups, periods, CPU sets, or kernel scheduling classes; actual CPU evidence must come from the matched workload experiment.