CPU quota: a shared time budget rather than dedicated cores

cpu.max supplies a maximum CPU-time budget and a period, conventionally expressed in microseconds by the interface. A quota of 150000 over period 100000 corresponds to 1.5 CPU-seconds per wall-clock second in the ideal average interpretation. It does not identify which CPUs will provide that time. The value max means no local quota restriction, but does not override an ancestor's finite budget, affinity restrictions, or competition. Read the effective hierarchy before concluding that an apparently unlimited child has unlimited execution capacity.

Threads in the same cgroup share the aggregate budget. If enough CPUs are available, parallel threads can consume several units of CPU time during one unit of elapsed time. Once the applicable budget is exhausted, runnable work can be throttled until replenishment. Actual accounting uses implementation mechanisms such as per-CPU runtime slices, so a simple rectangular budget picture is a teaching approximation. Short bursts, alignment, and configured burst behavior can differ from a naive exact cap on every arbitrary measurement window.

For an idealized fresh period with p continuously running threads on p available CPUs, a shared quota Q can be consumed in Q/p elapsed time. This estimate ignores slices, preemption, system overhead, and other constraints. If the interval is shorter than the period, later arrivals can wait behind throttling even when a whole-second utilization graph looks modest. A burst of request workers can therefore worsen tail latency without increasing the configured average budget. Measure the scheduling pattern before blaming the application's lock implementation.

CPU weight distributes contested fair-class capacity relative to siblings; it is not a hard ceiling or an idle-machine reservation. CPU placement and cpuset rules constrain where execution can occur, but selecting CPUs alone does not necessarily make them exclusive or eliminate shared-cache interference. Ancestor quota exhaustion can throttle a child that has local runtime remaining. With different periods, transient details require the real hierarchy, while steady aggregate budget reasoning still rules out interpreting a generous child limit as a promise of independent capacity.

Read cpu.stat counters and their units, including usage and throttling information, across a defined interval. A high ratio of throttled periods is not automatically the same percentage of wall time lost, and summing per-thread waiting can exaggerate a single request's delay. Correlate request arrival, runnable threads, CPU pressure, ancestor usage, and runtime versions. Compare a lower worker count, a different period, or an adjusted budget one at a time with the same workload. A quota change cannot promise a proportional application speedup if memory or I/O dominates.

The queue lab illustrates only offered work versus average service. Reset, explicitly set arrival four and service three, predict growth, then Play or Step. For a separate stable run Reset and explicitly set arrival two and service three before predicting and playing. The rates are normalized work items per second, not cpu.max fields. Edits preserve elapsed time and recompute from four initial jobs. This fluid curve cannot show quota-period bursts, throttled intervals, CPU weights, placement, or scheduler accounting.