FR
live

Linux 7.3-rc2 Fixes Cache-Aware Scheduling on Hybrid CPUs

The rc2 of Linux 7.3 fixes cache-aware scheduling misfits on hybrid CPUs and keeps migrating kernel allocations to kmalloc_obj. Test this rc2 if you run Intel Core hybrid or big.LITTLE machines.

Two metal gears of unequal size on a dark workbench, a single amber tooth lit on the smaller gear.

September 6, 2026. Linus Torvalds releases Linux 7.3-rc2, the second candidate of a cycle heading for the stable 7.3 in the second half of October. The rc2 carries a long-awaited scheduler fix for hybrid CPUs, a tree-wide memory migration to kmalloc_obj, and a notable security change around RandStruct and Rust. Why it matters: all three touch the performance and memory safety of the kernel your servers will run this autumn.

The scheduler learns not to strand tasks on efficiency cores

The most concrete fix concerns cache-aware scheduling on hybrid CPUs such as Intel Core (and Core Ultra). The mechanism groups related tasks on cores that share the same last-level cache (LLC) to improve cache locality and cut latency. But on asymmetric big.LITTLE designs, that grouping can backfire: heavy tasks were getting stuck on the E-cores, the small efficiency cores.

Tim Chen, an engineer at Intel, worked out the misfit fix. His patch forbids the LLC migration when a task fits its source CPU but would not fit the destination CPU, and vetoes the active balance under the same condition. Both checks are gated on hybrid processors only: symmetric systems are unaffected.

The fix locks down the two entry points of cache-aware migration. The can_migrate_llc_task() function refuses the LLC migration when a task would fit its source CPU but not the target CPU, while alb_break_llc() vetoes the active balance in the same situation. Tasks that already did not fit their source CPU stay under the existing LLC policy, which preserves misfit up-migration to the bigger cores.

The patch also sets a priority: when misfit tasks are found during the load-balancing classification phase, migrating them to a better-fitting CPU takes precedence over LLC aggregation. As Tim Chen explains, “a better fitting CPU will boost performance more than better cache locality.” In practice, your CPU-intensive workloads should stop landing on a hybrid chip’s efficiency cores.

For an SRE, the takeaway is practical: this is a performance fix, not a security fix. On hybrid laptops and workstations it keeps CPU-heavy threads off the efficiency cores, showing up as better interactive latency and throughput on mixed workloads. On symmetric server chips the LLC grouping logic is left untouched, so the change should be invisible.

A memory migration toward kmalloc_obj, safer and cleaner

The rc2 also lands a tree-wide conversion led by Kees Cook: more kmalloc() calls switch to the kmalloc_obj() family, introduced in Linux 7.0. A Coccinelle script touched hundreds of files and over 600 lines of allocations.

The benefit goes beyond aesthetics. The kmalloc_obj() helpers no longer require sizeof() or a type name: the allocator introspects the type of the target variable. That opens the door to type-aware hardening — alignment-aware choices, or per-allocation offset randomization that does not break alignment requirements. It is one more step toward an allocator that knows the shape of the objects it hands out, and therefore toward fewer overflows and type confusions.

The conversion shows both the ergonomic and the safety win. A classic kmalloc(sizeof(*p), gfp) becomes kmalloc_obj(p, gfp): the size is inferred from the first argument, and the return is no longer a generic void * but a typed pointer to the target’s type. The type can even be passed explicitly — kmalloc_obj(struct foo, gfp) — with the variable declared via __auto_type. That introspection enables alignment-aware choices and future type-sensitive hardening, two levers the old API could not offer.

c
/* before: the size had to be spelled out */
struct foo *p = kmalloc(sizeof(*p), GFP_KERNEL);
/* after: the type is inferred from the target */
struct foo *p = kmalloc_obj(p, GFP_KERNEL);

RandStruct backs off by default when Rust is present

The third signal is a security tradeoff worth watching. The rc2 disables RandStruct — GCC’s structure-layout randomization — by default when Rust support is present with a Rust compiler toolchain. RandStruct makes kernel exploits harder by breaking predictable offsets; seeing it retreat in Rust-enabled builds means the memory-safety gain from Rust code comes, in those configurations, with a partial give-up on structure randomization.

The choice fits the kernel’s long-term strategy: Rust is positioned as the structural answer to memory bugs, to the point that RandStruct activation becomes conditional. Still, an administrator who compiles their own kernel should know what they gain and lose depending on whether Rust is enabled.

RandStruct is GCC’s structure-layout randomization: it shuffles the order of struct fields so a kernel exploit cannot hard-code the offsets it needs. Losing it in Rust-enabled builds is not a bug — the kernel’s Rust tooling currently assumes stable layouts — but it is a concrete reduction in exploit friction for those builds. The tradeoff is deliberate: Rust’s compile-time memory safety is meant to prevent the very bugs RandStruct hardens against, yet the two defenses do not overlap perfectly.

A dense cycle, owned by Torvalds

The rc2 confirms the earlier diagnosis. Greg Kroah-Hartman had warned of a “rough” cycle due to the steady influx of AI/LLM-generated fixes. Linus Torvalds, in his slightly delayed announcement, owns it: “This didn’t feel like a particularly busy rc2, but it clearly was… this is a “full fat” rc release.” He points to fixes from several filesystems, a sizable drm pull, networking and bpf fixes, and plenty of driver trees.

The kernel now exceeds 41 million lines of source. The cycle’s density makes testing all the more valuable: regressions found on 7.3-rc2 are precisely what needs surfacing before October’s stabilization.

The scheduler misfit fix stands out precisely because it is a hand-written correctness patch in a cycle dominated by machine-generated churn — a reminder that the most consequential changes in a noisy merge window are often the quiet ones.

The cycle is not just these fixes. The 7.3 feature overview promises faster Btrfs and a broad wave of hardware support, while early AMD EPYC benchmarks on 7.3 hint at performance gains on the horizon. The rc2 is thus less a routine step than a pivot point: what gets fixed here will shape the quality of October’s stable release.

Also worth noting: the rc2 carries Nouveau display fixes for NVIDIA Blackwell GPUs and brings in the EDAC changes that were forgotten during the merge window. The detail captures the cycle’s density — even what was not absorbed in time still finds its way back into the rc2 flow.

Verdict

If you run servers or desktops on hybrid CPUs (Intel Core Ultra, big.LITTLE chips), test 7.3-rc2 on a non-critical subset and confirm your CPU-intensive workloads no longer land on E-cores: Tim Chen’s fix is a direct performance win.

If you compile your own kernel, revisit your RandStruct and Rust configuration: the changed default shifts what you enable implicitly, and deserves an explicit decision.

If you do not touch the kernel, wait for stable 7.3 in October, but note that the kmalloc_obj migration and the scheduler fix arrive without any action on your part, via your distribution.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

The first Linux patches boot the MacBook Neo on a single core of its A18 Pro

In early September 2026, developer Yureka Lilian posted the first Device Tree patches for the Apple A18 Pro SoC in the MacBook Neo, with support still limited to a single CPU core. It is the first concrete step toward Linux support on Apple’s entry-level laptop, but daily use is months away.

← Back to the feed

Type at least two characters.

navigate open esc dismiss