Cache Aware Scheduling fixes land for Linux 7.3 and 7.2
Intel engineer Tim Chen's Cache Aware Scheduling fixes merged into tip/tip.git's sched/urgent branch for Linux 7.3, with backports to 7.2.
If you're running Linux 7.2 on a multi-core system, the scheduler has been quietly failing to do one of its core jobs. Cache Aware Scheduling shipped in that kernel with the explicit purpose of keeping related tasks on cores that share the same last-level cache. For the past cycle, bugs have meant that grouping wasn't happening reliably. The result: your everyday workloads were paying the latency cost of cache bouncing that the feature was designed to eliminate. You didn't notice because the degradation is subtle, but it was there.
The mechanism is straightforward. CAS tells the scheduler to prefer placing tasks that share data onto cores within the same LLC domain, reducing the chance that a cache line gets invalidated by a sibling core pulling in different data. Intel engineer Tim Chen has been patching the implementation since 7.2 landed. The specific fixes in this round: keeping nr_pref_llc_running in the runnable domain, honoring migrate_llc_task semantics during active load balancing, refreshing LLC capacity when CPUs are hotplugged, and excluding kernel threads from CAS grouping. Each one addresses a code path where the scheduler could misplace a task or lose track of cache topology after a topology change.
Before these patches, a user on 7.2 with a multi-socket or large-core-count system was effectively running a scheduler that ignored LLC boundaries in certain code paths. The load balancer could migrate a task across LLC domains without respecting the migrate_llc_task flag, and hotplug events could leave stale capacity values that skewed placement decisions. After the fix, the scheduler should honor those boundaries consistently. The practical effect for a desktop or workstation user: fewer cache misses on workloads that keep multiple threads alive simultaneously, which is most of what people actually run. Compiling, running a browser with many tabs, or editing a large project all benefit from tighter cache locality.
What the source does not provide: any benchmark numbers. No latency figures, no throughput deltas, no before/after comparison. Phoronix notes it will be "interesting to revisit the Cache Aware Scheduling benchmarking" with these fixes, which is a polite way of saying nobody has published results yet. The source also does not specify which CPU topologies benefit most, though the mention of hybrid CPU fixes earlier in the cycle suggests Intel's mixed-core designs are a primary target.
Watch for the 7.3 merge later this week and the 7.2 backport landing in a stable update. If you're on 7.2, the backport is the one to track. Phoronix will likely run its Phoronix Test Suite benchmarks once the patches are in a release kernel. That's when the numbers appear.
Desk take
The fixes correct scheduler state tracking (nr_pref_llc_running, LLC capacity on hotplug) and load-balance migration semantics that were causing CAS to silently degrade on multi-LLC systems. No performance data is published yet; the practical impact depends on workload thread affinity and LLC topology.
Correct LLC-aware placement reduces cross-domain cache invalidation, directly lowering tail latency on multi-threaded workloads.
Source dispatch
Later this week it looks like the latest round of Cache Aware Scheduling fixes will be merged for enhancing this kernel scheduler functionality for grouping related tasks together on CPU cores that share the same last level cache (LLC). Cache Aware Scheduling can lead to better cache locality and lower latency by avoiding the costs of potential cache bouncing -- that is when bugs don't get in the way...

