Linux 7.3 changes how the fair scheduler chooses a task within a cgroup hierarchy. The new single-runqueue description does not mean all CPUs share one global queue, or that cgroup weights and accounting disappear.
Preserve the hierarchy, simplify the selection
The August 17 scheduler pull request includes Peter Zijlstra’s work to flatten task selection. The implementation commit shows exactly what changes: intermediate groups remain for load tracking and enqueue/dequeue operations, while EEVDF selection operates directly on tasks in the root fair runqueue for that CPU.
Effective task weights still derive from the hierarchy. The selection structure becomes flatter; the resource-control structure is retained. The author explicitly says this does not immediately eliminate the performance cost of the remaining hierarchical operations.
For a conceptual example, suppose group A contains tasks A1 and A2 and group B contains B1. All three can be candidates in the same CPU’s fair selection structure. That does not entitle each to an unconditional one-third share: group weights, task weights, runnable state and other controls still matter. A second CPU has its own scheduling state.
The default changes, but old tuning still matters
The series adds up, max, concur and tasks weight-distribution modes, with concur the default. The default-setting commit warns that existing users may have compensated for old behavior by inflating weights. A changed calculation can make that old tuning behave differently.
Consequently, “no configuration required” only means the kernel supplies a default. It does not establish that a fleet’s existing weights, CPU affinity and quotas are already appropriate. The old article’s broad prediction of gaming and server gains exceeded the evidence.
Include the September throttling correction
A September 2 follow-up corrects throttle_cfs_rq to examine the current entity at the relevant hierarchy level. Using the flat current-task field for an intermediate group could miss its running entity and defer the required throttling work.
This is why evaluating an early merge-window snapshot and a later corrected kernel are different exercises. Record the actual build or distribution backports, rather than just writing “7.3” beside a latency result.
For an original evaluation plan, run a latency-sensitive service beside a controlled CPU batch load. Keep affinity, weights and quotas unchanged, then compare request percentiles, achieved CPU share and throttled time. An improvement in average throughput alone cannot prove that quota behavior or tail latency is correct. This plan is proposed; no scheduler benchmark was run on the shared VPS.
Explain per-CPU flattening while preserving hierarchy and weight, remove universal gaming claims and add September throttle correction.