Linux 7.2 attracted 254 points on Hacker News, but its most useful lesson arrived at the end of the release cycle: maintainers backed away from enabling a fairer GPU scheduler by default after a regression appeared during rc7. The code still shipped, but behind an opt-in. For developers, that decision matters more than the round version number. This is a large kernel release that changes how Linux places work across CPU caches, manages memory, serves storage and powers Raspberry Pi graphics, yet it also shows why a feature being merged is not the same as a feature being ready to govern every machine.
The kernel was tagged on August 16 and is now listed by kernel.org as the mainline 7.2 release. According to Igalia's release review, the cycle was one of the busiest in Linux history, surpassed only by 6.7. That size is not a reason to upgrade blindly. It is a reason to separate changes that alter defaults from capabilities that administrators and distribution maintainers can test on their own schedules.
A fairer GPU queue, with the old default preserved
The Direct Rendering Manager scheduler coordinates jobs submitted to GPUs by multiple clients. A simple first-in, first-out policy can work adequately when one application dominates the device. It becomes less convincing when a desktop compositor, browser, game, compute process and background task all compete for time. A heavy client can make an interactive one feel sluggish even when the latter needs only brief bursts of GPU access.
Linux 7.2 contains a fair scheduling policy intended to improve those mixed workloads. The patch set accounts for how much GPU time clients consume and slightly favors interactive clients. The practical goal is not to make a GPU faster. It is to divide access more sensibly so a demanding queue does not make the rest of the desktop unresponsive.
The policy had been scheduled to become the default. A regression reported during the rc7 week changed that plan. The relevant commits were reverted and the fair policy was marked experimental, leaving FIFO as the default. Igalia says the cause is understood and early testing of a fix is promising, but it does not attach a release date to re-enabling the policy. That distinction is important: Linux 7.2 includes the work for evaluation, not a promise that all users will receive it automatically.
This is the right sort of conservatism for a kernel. A scheduler can look better in benchmarks and still expose timing assumptions in a driver or workload that broad testing did not cover. Operators interested in the policy can now test it against real multi-client GPU use, while ordinary systems keep the known behavior. What to measure is also clear: latency and responsiveness under contention, not only aggregate throughput.
CPU scheduling gets cache awareness
The CPU scheduler changes are less dramatic to describe but more likely to affect a broad range of systems. Linux 7.2 merges cache-aware load balancing. As LWN's first-half release summary explains, the scheduler can try to group processes that share resources inside the same cache domain. Keeping related work near shared cached data can reduce expensive movement and improve performance, although the result will depend on topology and workload.
This is particularly relevant on modern servers where core count alone gives an incomplete picture of the machine. Cores may share some cache levels but not others, and sending a task to an apparently idle CPU can cost more if its useful data must be fetched again. Cache-aware placement gives the scheduler another signal beyond immediate utilization. Application developers do not need a new API, but performance teams should watch for changed placement behavior when comparing 7.2 with an older kernel.
The extensible scheduler framework, sched_ext, also gains better failure diagnostics. If a custom BPF scheduler fails at runtime, such as by leaving a task unscheduled for more than 30 seconds, the kernel ejects it and falls back to the standard scheduler. On high-core-count systems, the resulting CPU-state dump could exceed the buffer connecting kernel and user space, hiding the CPU that triggered the failure. Linux 7.2 prioritizes that exit CPU in the dump and exposes its ID to BPF schedulers and user-space tools. This does not prevent a faulty scheduler, but it should make the fault easier to reconstruct.
Work on sched_ext sub-schedulers is continuing too. The idea is to let scheduling policies operate beneath a broader scheduler, which could eventually make specialization more composable. It remains an area for kernel and infrastructure engineers to follow rather than a reason for general users to change configuration today.
Memory and storage defaults move forward
Linux 7.2 also advances the kernel's long-running shift toward larger memory units where they make sense. The khugepaged thread can now create multi-size transparent huge pages automatically. Instead of treating huge pages as one oversized alternative to the normal page size, the kernel can use intermediate sizes that better fit a workload and the available memory. The intended payoff is lower page-table and translation overhead without requiring every allocation to jump to the largest size.
Btrfs now uses large folios by default, while support for folios as large as 2MB is available experimentally. XFS support for zoned storage is no longer marked experimental. These changes occupy different layers, but they point in the same direction: the kernel is becoming more deliberate about matching the unit of memory or I/O to current hardware rather than assuming one small unit is ideal everywhere.
The filesystem changes include tradeoffs. LWN's second-half summary notes that a workaround for creating transparent huge pages in the page cache for read-only files has been removed. Filesystems without native large-folio support may therefore lose some performance until they implement it. NFS, meanwhile, raises its default transfer block size to 4MB on machines with at least 16GB of RAM. The in-kernel SMB server adds handling for compressed files and compression of network data, while NTFS receives more protection against corrupted on-disk metadata and support for Windows-native symbolic links.
Those are not interchangeable wins. Larger transfers can improve throughput but also change memory pressure and latency. Compression saves network capacity at a CPU cost. Distribution kernels and storage operators will still need workload-specific testing, particularly around mixed I/O and constrained systems.
Raspberry Pi GPUs finally sleep when idle
One concrete 7.2 improvement is easier to measure. The V3D driver for Raspberry Pi 4 and 5 can now use runtime power management, allowing the GPU clock to shut down when no graphics work is running. Previously, the clock stayed enabled for the lifetime of the driver even if the GPU was idle.
Kernel contributor Maíra Canal measured the change with an external power meter. In an idle desktop session, average board draw fell from 3.30W to 3.19W. Without a compositor, it dropped from 3.18W to 3.09W. Both reductions were about 0.1W, or roughly 3 percent. During the glmark2 graphics benchmark, the difference narrowed to 0.015W because the GPU was busy, which is the expected pattern for a feature aimed at idle periods.
The absolute saving is modest, but it applies automatically beneath applications and can reduce heat as well as energy use. The same release fixes long-standing Raspberry Pi 3 graphics bugs tied to tile-memory handling, which could produce random GPU hangs and full system crashes in RetroPie. It also includes fixes intended to make GPU resets more reliable on Raspberry Pi 4 and 5.
Networking, Rust, and old interfaces
Multi-path TCP can now use as many as 64 subflows, up from eight. MPTCP can spread a connection across multiple paths, so the higher ceiling expands what specialized networking setups can construct. It does not mean ordinary connections will suddenly open dozens of paths; peers, policy and available interfaces still determine actual use. Work also continues to reduce dependence on the networking stack's large RTNL lock, an incremental effort aimed at better scalability.
At the same time, the kernel continues removing support whose maintenance cost no longer makes sense. Linux 7.2 drops networking support for ISA and PCMCIA ARCnet hardware and PCMCIA Bluetooth adapters. The AF_ALG interface, which exposes kernel cryptography to user space, is now deprecated after being associated with security problems; hardware-accelerator support has been removed from it, leaving software implementations. Deprecation signals intent, not immediate disappearance, but maintainers of software that relies on AF_ALG should start auditing that dependency.
Rust support reaches the s390 architecture, and the kernel source now includes the zerocopy crate for low-cost memory manipulation with checks intended to preserve safety. The minimum LLVM version for building the kernel rises to 17.0.1. Those build-system facts are easy to miss in feature lists, yet they can be the first practical blocker for teams compiling kernels in older enterprise environments. Toolchain validation belongs near the start of an adoption plan, not after a failed production build.
Upgrade for a requirement, not the version number
Linux 7.2 is mainline, while stable and long-term branches remain the sensible destination for many production systems. Developers who need new device support, Raspberry Pi runtime power management, a specific filesystem improvement or sched_ext diagnostics have concrete reasons to begin testing. Everyone else can let distributions integrate the release, carry fixes and decide which options to expose.
The next signals to watch are narrower than the headline version: whether the DRM fair scheduler's regression fix survives wider testing and becomes the default, how cache-aware CPU placement behaves outside targeted benchmarks, and whether filesystems close the large-folio gap exposed by the removed page-cache workaround. Linux 7.2 provides the machinery for each of those stories, but the results will come from deployment evidence rather than the merge itself.