Linux 7.2-rc4: Cache-Aware Scheduling, Rust, and More

Linux 7.2-rc4: Cache-Aware Scheduling, Rust, and More

Linux 7.2-rc4 is shaping up to be a significant kernel release, with improvements spanning CPU scheduling, memory management, filesystems, Rust integration, security, and handheld gaming hardware.

The release candidate also reflects a broader change in kernel development. Linus Torvalds described the current development cycle as “pretty normal” while noting that AI agents are increasingly involved in identifying, reporting, and preparing fixes for kernel bugs and vulnerabilities. The result is a substantially higher volume of candidate patches than developers historically handled through entirely manual workflows.

Among the most consequential changes are Cache Aware Scheduling (CAS), additional memory-reclaim optimizations, the completion of the kernel-wide strncpy() removal effort, expanded Rust infrastructure, and hardware-specific fixes for devices such as the ASUS ROG Ally X.

Cache-Aware Scheduling Brings CPU Topology Into Scheduling Decisions

#

Modern CPUs increasingly rely on complex cache hierarchies. Multi-CCD AMD processors, for example, can divide cores across cache domains, while Intel hybrid architectures introduce additional differences between processor clusters.

Historically, Linux scheduling decisions did not fully account for the performance cost associated with moving a task between these cache domains. A task could be migrated to an otherwise idle CPU even when another CPU within the same cache locality would provide better access to its working set.

Linux 7.2 introduces Cache Aware Scheduling through CONFIG_SCHED_CACHE, allowing the scheduler to incorporate CPU cache topology into task placement decisions.

Why Cache Locality Matters

#

When a task moves between cache domains, portions of its working set may need to be fetched again from lower-level caches or system memory. For latency-sensitive and cache-intensive workloads, repeated migrations can therefore introduce measurable performance penalties.

CAS attempts to reduce those migrations by keeping tasks closer to the cache hierarchy where their working data is already available.

The feature follows more than a year of upstream development and review and is particularly relevant to systems with multiple cache clusters.

Database and Kernel-Level Performance

#

Benchmark results associated with the broader scheduling and memory-management work show substantial improvements in selected workloads:

These results should not be interpreted as universal gains across all workloads. They demonstrate that cache locality and related kernel-path optimizations can have a disproportionate effect on workloads sensitive to memory access and scheduling behavior.

MGLRU Also Improves Memory Reclaim

#

Linux 7.2 also continues refining Multi-Generational LRU (MGLRU) behavior in the memory-management subsystem.

The updated reclaim path improves dirty-page writeback decisions under memory pressure. This matters for workloads such as MongoDB where the active dataset can exceed physical RAM and trigger frequent page reclamation.

More accurate eviction and writeback decisions can reduce unnecessary disk I/O and improve workload consistency when the system is operating close to its memory limits.

strncpy() Finally Leaves the Linux Kernel

#

One of the most notable kernel-maintenance milestones in Linux 7.2 is the completion of the long-running effort to eliminate strncpy() from the kernel source tree.

The C library function has two characteristics that make it problematic for kernel code.

First, strncpy() does not guarantee null termination when the source string is at least as large as the destination buffer. Code that subsequently treats the destination as a conventional C string can therefore encounter invalid reads.

Second, strncpy() zero-fills the unused portion of the destination buffer when the source string is shorter than the requested length. For large buffers, this can introduce unnecessary memory writes.

Six Years of Kernel Cleanup

#

The kernel community began systematically removing strncpy() in 2020, replacing it primarily with safer alternatives such as strscpy() where appropriate.

After roughly six years of work and more than 360 patches, the migration has reached its final stage. The Linux kernel source tree no longer contains strncpy() usage.

Although this change has little visible impact for desktop users, it represents an important improvement in kernel code quality, memory-safety practices, and long-term maintainability.

Filesystem and Storage Performance Improvements

#

Linux 7.2 includes several lower-level storage improvements that target filesystem throughput, memory overhead, and high-IOPS workloads.

Btrfs Enables Large Folios by Default

#

Large folio support that previously required experimental configuration for Btrfs is now enabled by default.

Folios allow the kernel to manage multiple physically contiguous pages as a larger memory-management unit. This reduces per-page bookkeeping and can improve efficiency for workloads involving large sequential transfers or substantial page-cache activity.

Linux 7.2 also introduces experimental support for larger folios of up to 2 MB.

Reported benchmark results include:

The actual benefit depends heavily on workload characteristics, I/O configuration, and storage hardware.

EXT4 and XFS Remove Redundant Memory Writes

#

A targeted VFS optimization also improves the iomap_iter() path shared by filesystems including EXT4 and XFS.

The previous implementation cleared the iomap structure with memset() after each iteration. Because callers immediately discarded the structure afterward, the operation provided no meaningful functional benefit in the relevant path.

Removing this redundant memory write improves efficiency for workloads that repeatedly exercise the mapping layer.

In testing involving 4K random reads and NVMe polling through io_uring, the change produced approximately 5% IOPS improvements for both EXT4 and XFS.

EROFS Targets Sparse AI Datasets

#

EROFS also receives structural optimizations aimed at large sparse datasets.

The filesystem is increasingly relevant to AI infrastructure, where training and inference workloads can involve multi-terabyte datasets with sparse storage characteristics. The Linux 7.2 changes target more efficient processing and improved throughput for these workloads.

ASUS ROG Ally X Audio Support Finally Works

#

Linux users running distributions such as Bazzite, ChimeraOS, Fedora, or Ubuntu on the ASUS ROG Ally X have faced audio issues involving both headphone output and headset microphone input.

Linux 7.2-rc4 includes dedicated Realtek HDA fixes addressing these problems.

Two patches specifically target the handheld:

• ALSA: hda/realtek: Fix headphone output on ASUS ROG Ally X
• ALSA: hda/realtek: Fix headset mic on ASUS ROG Ally X

The first restores headphone output, while the second addresses headset microphone capture.

Options for ROG Ally X Users

#

Users who need these fixes can choose between several deployment paths:

For production systems, waiting for the distribution’s stable kernel package avoids the additional risks associated with release candidates and manually maintained kernel builds.

Linux 7.2 also contains other handheld-oriented work, including OneXPlayer driver support, sched_ext changes, and AMDGPU HDMI 2.1 FRL-related development.

Rust Integration Expands With zerocopy

#

Rust continues to move deeper into the Linux kernel development model.

Linux 7.2 adds more than 40,000 lines of Rust-related code, with approximately 39,000 lines coming from the zerocopy infrastructure.

What zerocopy Provides

#

The zerocopy ecosystem provides abstractions for safely interpreting and converting between byte sequences and typed data while preserving compile-time guarantees and avoiding unnecessary runtime overhead.

For kernel Rust code, this reduces the amount of manually written unsafe code required for common memory-reinterpretation operations.

The integration also demonstrates that kernel Rust development is moving beyond isolated experimental drivers toward reusable infrastructure.

NVIDIA Nova Benefits From the Infrastructure

#

The NVIDIA Nova driver is an early consumer of the new infrastructure, using it to reduce explicit unsafe impl requirements without introducing additional runtime overhead or panic paths.

This is significant because reusable safety infrastructure can reduce the cost of writing and maintaining new Rust-based kernel components.

AutoFDO and Rust KASAN

#

Linux 7.2 also expands tooling around Rust kernel development.

AutoFDO support allows Rust kernel code to use compiler profiling data for feedback-directed optimization. Reported Rust Binder benchmark results show performance improvements of roughly 13% in relevant tests.

Rust support for software-tag-based Kernel Address Sanitizer (KASAN) further improves memory-debugging capabilities for Rust code inside the kernel.

Together, these changes indicate a shift from proving that Rust can operate inside the kernel toward optimizing and debugging production-oriented Rust components.

Security, Hardware, and Kernel Infrastructure Updates

#

Linux 7.2-rc4 contains a broad collection of additional subsystem changes.

Apple M3 Boot Support

#

Initial mainline support now allows Linux to boot on Apple M3 hardware.

The work remains at an early proof-of-concept stage, so successful booting should not be confused with full hardware support suitable for daily use.

Intel TDX Runtime Improvements

#

Intel Trust Domain Extensions (TDX) receives runtime update capabilities designed to allow security-related changes without requiring applications to restart.

This strengthens the operational model for confidential-computing environments where minimizing service disruption is important.

Post-Quantum ML-DSA Support

#

The Linux integrity subsystem adds support for ML-DSA, the post-quantum digital signature algorithm standardized as FIPS 204.

Integration into IMA/EVM certificate and module verification establishes a foundation for post-quantum authentication within kernel integrity mechanisms.

KUnit JUnit XML Output

#

KUnit can now generate JUnit-compatible XML output, making it easier to integrate kernel unit tests into conventional CI/CD systems.

This is particularly useful for automated kernel validation pipelines that already consume JUnit test artifacts.

sched_ext Refactoring

#

The extensible scheduler framework, sched_ext, has undergone additional structural cleanup following design feedback during upstream review.

The refactoring improves the maintainability of the framework while keeping it suitable for experimentation with alternative scheduling policies.

OneXPlayer and USB4STREAM

#

Linux 7.2 adds mainline driver support for OneXPlayer handheld hardware.

USB4STREAM support also introduces high-speed, low-latency media streaming capabilities over USB4 connections.

Timer-Based DoS Protection

#

Additional defenses target denial-of-service attacks involving kernel timer arming operations, strengthening protection against workloads that attempt to abuse timer-management paths.

Ubuntu 26.10 and the Linux 7.2 Timeline

#

Linux 7.2 is also relevant to upcoming Ubuntu releases, with Ubuntu 26.10 expected to use the kernel as part of its platform stack.

The projected schedule is:

For Ubuntu users, Linux 7.2-rc4 therefore provides an early view of kernel capabilities expected to become relevant during the Ubuntu 26.10 development cycle.

Testing Linux 7.2-rc4

#

Advanced users can test the release candidate through a mainline kernel package, a development build, or by compiling the upstream source directly.

For example, a source build can begin with:

git clone --depth=1 -b v7.2-rc4 \
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

cd linux
make olddefconfig
make -j"$(nproc)"
sudo make modules_install
sudo make install

Release candidates should be treated as development kernels rather than production replacements. Kernel installation procedures also vary across distributions, boot configurations, Secure Boot setups, and package-management environments.

AI-Assisted Kernel Development Becomes Part of the Workflow

#

Perhaps the most consequential change surrounding Linux 7.2 is not a specific subsystem feature but the evolution of how the kernel itself is developed.

AI agents are increasingly participating in the bug lifecycle: identifying potential defects, generating reports, proposing patches, and assisting with fixes.

Torvalds’ characterization of this activity as part of the “new normal” highlights an important transition. The challenge is no longer simply whether AI can generate kernel patches, but how maintainers validate, review, test, and integrate an increasingly large volume of machine-assisted changes.

For a project as complex as the Linux kernel, human review remains essential. AI-generated patches still need to satisfy architectural constraints, regression testing, subsystem-specific conventions, and long-term maintainability requirements.

The difference is that AI-assisted development is increasingly becoming another input into the existing kernel engineering pipeline rather than an isolated experiment.

Linux 7.2 Is More Than a Routine Point Release Candidate

#

Linux 7.2-rc4 combines several changes that affect different layers of the kernel stack.

Cache-aware scheduling brings hardware cache topology directly into scheduling decisions. MGLRU and filesystem changes improve memory and storage efficiency. The removal of strncpy() completes a multi-year kernel cleanup effort. Rust gains substantial reusable infrastructure, while security work expands into post-quantum signatures and stronger runtime protections.

For handheld users, the ROG Ally X audio fixes and OneXPlayer support address practical hardware compatibility issues. For developers, KUnit, Rust tooling, sched_ext, and AI-assisted workflows point toward a kernel development process increasingly optimized for automation and continuous validation.

Linux 7.2 is therefore notable not because of one isolated feature, but because improvements across scheduling, memory management, storage, hardware enablement, security, and development infrastructure are converging in the same release cycle.