Linux 7.2 hit its third release candidate on Sunday, July 12, 2026, and Linus Torvalds described it as unremarkable, which at this point in a cycle is the highest praise available. The feature worth knowing about landed earlier in the merge window. Cache aware scheduling, built by Intel engineers over more than a year, tries to keep tasks that share data on the same last level cache instead of scattering them across a chip. If you run workloads on modern many core server processors, this is the release to start testing, because the stable kernel is expected in August.
The short answer
Linux 7.2 reached its third release candidate on July 12, 2026, with Linus Torvalds noting that nothing looks particularly scary or strange and that about half the changes are drivers. The headline feature of the cycle is cache aware scheduling, led by Intel engineers for more than a year, which colocates tasks that share data onto the same last level cache domain to improve locality. It is built with CONFIG_SCHED_CACHE and can be toggled at runtime through an enabled knob in the llc_balancing debugfs directory. Stable is expected in August 2026.
Most kernel releases are worth a changelog skim and nothing more. This one has something in it that can change the shape of your performance numbers without you touching a line of code, which is a category of change we pay closer attention to. Linux 7.2 reached its third release candidate on Sunday, July 12, 2026, and it is carrying cache aware scheduling.
The problem it solves
Start with the hardware, because the feature only makes sense against it.
A modern server processor does not have one big cache shared by every core. It has several last level cache domains, each shared by a group of cores. Which group you land in is a physical fact about where your task is running. Two cores in the same domain share a last level cache. Two cores in different domains do not.
Now put two tasks that work on the same data on two cores in different domains. Every time one writes something the other reads, that data has to move between cache domains. The cache line bounces back and forth, and each bounce costs far more than a hit in local cache would. Neither task is doing anything wrong. They are simply in the wrong places relative to each other, and the scheduler put them there without knowing they were related.
The scheduler has historically optimised for keeping cores busy and spreading load evenly, which is a reasonable goal that happens to be indifferent to this problem. Balancing tasks across a chip is exactly the behaviour that separates tasks sharing data.
What cache aware scheduling does
Cache aware scheduling teaches the scheduler to care about that relationship. It tries to ensure tasks sharing data are colocated in the same last level cache domain, improving cache locality and reducing the cache misses and cache line bouncing that come from splitting them up.
The work has been led by Intel software engineers for more than a year, with Peter Zijlstra managing the sched/cache branch, and it entered the tip sched/core branch in May 2026 before merging during the 7.2 window. Phoronix reports benefits on modern Intel and AMD processors, particularly server class parts with more cores and bigger caches, citing gains on AMD EPYC processors and Intel Xeon 6 systems.
We are deliberately not quoting a speedup percentage here. Several outlets have attached specific benchmark numbers to this feature, and we could not confirm them against the kernel reporting we trust, so we are leaving them out rather than passing along figures we cannot stand behind. The honest summary is that the direction is well established and the magnitude depends entirely on your workload, which is the answer you would want to verify yourself anyway.
How to try it
Two knobs matter.
The feature is compiled in through the CONFIG_SCHED_CACHE Kconfig option, so it has to be present in the kernel build. Once it is there, a debugfs directory named llc_balancing contains a knob called enabled that turns the behaviour on and off at runtime, without a rebuild and without a reboot.
That runtime toggle is what makes this evaluable rather than merely interesting. You can run your actual workload on your actual machine, flip the knob, and run it again. Same kernel, same hardware, same everything else. That is a far better experiment than comparing across kernel versions, where a hundred other changes are in flight and any one of them could explain a difference.
Worth saying plainly: a scheduler change is precisely the kind of thing that helps most workloads and hurts a few. If your tasks genuinely share data, colocating them is a win. If your workload is many independent tasks that share nothing and mostly want raw parallel throughput and memory bandwidth, packing them into fewer cache domains is not obviously helping and could contend for the same cache. This is why the toggle exists, and why measuring beats assuming.
The rest of the cycle
For the release candidate itself, Torvalds said nothing looks particularly scary or strange, with about half the changes in drivers and the rest spread across networking, filesystems, documentation, core kernel and architecture fixes. Specific items in rc3 include Ultra RISC-V support added to the default RISC-V configuration, improved display detection for some multi GPU systems, and SEGA Dreamcast driver fixes. The broader 7.2 merge window also brought initial HDMI 2.1 FRL support to the AMDGPU driver and further work on the kernel's Rust support.
The timeline is the actionable bit. Weekly release candidates through July point at a stable 7.2 around August 2026, and 7.2 is expected to become the default kernel for Ubuntu 26.10 in the autumn. That gives you a window now, on hardware you control, to find out what this does to your workload before it arrives in a distribution and starts explaining a graph you did not expect. Testing during the release candidate window is also when a regression report still reaches people who can act on it.
Sources and further reading
- Phoronix: Linux 7.2-rc3 released, close to the new normal
- Phoronix: The very exciting cache aware scheduling looks like it will land for Linux 7.2
- OSTechNix: Linux kernel 7.2 rc3 released, testing the new normal
- Neowin: Normal-looking Linux 7.2-rc3 lands with fixes for SEGA Dreamcast driver
- LinuxCompatible: Linux kernel 7.2-rc3 released, driver patches, RISC-V support and SEGA Dreamcast fixes
- 9to5Linux: Linus Torvalds announces first Linux kernel 7.2 release candidate
Frequently asked questions
What is cache aware scheduling?
It is a change to the Linux task scheduler that tries to place tasks which share data onto the same last level cache domain. On a processor with several last level caches, two tasks working on the same data can end up on cores that do not share a cache, so every access to that shared data has to travel between cache domains. Cache aware scheduling tries to keep those tasks together, improving cache locality and cutting down on cache misses and cache line bouncing.
How do I enable it?
The feature is built in through the CONFIG_SCHED_CACHE Kconfig option, so your kernel has to be compiled with it. At runtime there is a debugfs directory called llc_balancing containing a knob named enabled, which lets you turn the behaviour on and off without rebuilding or rebooting. That runtime toggle is the useful part for evaluation, because it lets you measure the same workload with the feature on and off on the same machine.
Which processors benefit?
The work targets modern Intel and AMD processors that expose multiple last level cache domains, and the benefit grows with core count and cache size. Server class parts are the clear case, and Phoronix reports gains on AMD EPYC processors and Intel Xeon 6 systems. If your machine presents a single last level cache shared by every core, there is nothing for the feature to rearrange, so do not expect a change.
When does Linux 7.2 ship as stable?
Linux 7.2 reached its third release candidate on July 12, 2026, and the cycle is running to the normal weekly rhythm, which points at a stable release around August 2026. Linux 7.2 is expected to become the default kernel for Ubuntu 26.10 in the autumn. Nothing is guaranteed, since Linus extends a cycle by an extra release candidate when something warrants it, but as of rc3 there is no sign of that.
What else is in the 7.2 release candidates?
Torvalds said about half the changes in rc3 are drivers, with the rest spread across networking, filesystems, documentation, core kernel and architecture fixes, and that nothing looks particularly scary or strange. Specific items include Ultra RISC-V support added to the default RISC-V kernel configuration, improved display detection for some multi GPU systems, and SEGA Dreamcast driver fixes. The wider 7.2 merge window also brought initial HDMI 2.1 FRL support to the AMDGPU driver and continued work on the kernel's Rust support.
Should I test rc3 in production?
No. Release candidates are for testing on hardware you can afford to break, not for production. The reason to care now is that cache aware scheduling is a scheduler change, and scheduler changes interact with real workloads in ways that synthetic benchmarks do not always predict. Testing your workload during the release candidate window is how you find out before the stable kernel reaches your distribution, and it is also when a regression report is still useful to the people who can fix it.