Skip to main content

Linux 7.3: Chinese Kernel Optimizations and AI-Assisted Debugging

·1791 words·9 mins
Linux 7.3 Linux Kernel Kernel Development BPF RISC-V AI Hardware Memory Management Scheduling Open Source
Table of Contents

Linux 7.3: Chinese Kernel Optimizations and AI-Assisted Debugging

The Linux 7.3 merge window is shaping up to be a significant kernel development cycle, with substantial work landing across memory management, scheduling, filesystems, hardware enablement, and AI infrastructure.

Among the most notable changes are production-driven optimizations from Chinese engineering teams targeting severe latency and lock-contention bottlenecks, as well as a high-profile debugging session in which Linus Torvalds used Gemini AI while diagnosing an Intel graphics driver failure.

The cycle also expands Linux support for AI accelerator interconnects, BPF-based scheduling, Apple Silicon, Rust on PowerPC, hybrid CPU architectures, and high-performance storage.

🚀 Production-Scale Memory and Scheduler Optimizations
#

Several patches merged during the Linux 7.3 cycle address problems that are difficult to expose through conventional benchmarks because they appear primarily under heavy production workloads.

The common theme is reducing tail latency, lock contention, and synchronization overhead in highly concurrent systems.

ByteDance cuts SMP tail latency by roughly 90%
#

ByteDance engineer Chuyi Zhou addressed a latency problem involving the kernel’s smp_call_function*() family.

The existing implementation can disable preemption while waiting for target CPUs to acknowledge Inter-Processor Interrupts (IPIs). On heavily loaded systems, this can create substantial scheduling delays.

In production environments with 16-core systems, the resulting tail latency could reach approximately 16 ms, creating problems for latency-sensitive networking frameworks such as DPDK.

The proposed solution records the target CPU wait state in each task’s local cpu_mask.

By moving the relevant state from a global waiting condition into task-local data, the kernel can re-enable preemption before completing the wait.

The reported result is significant:

Metric Before After
Worst-case latency ~17 ms ~1.5 ms
Reduction Baseline ~90%
Target workload DPDK / latency-sensitive tasks DPDK / latency-sensitive tasks

The change followed approximately ten rounds of review before being merged.

ZTE reduces KSM lock contention
#

ZTE engineer Xu Xin identified another severe latency bottleneck involving Kernel Samepage Merging (KSM) and the reverse-mapping path in rmap_walk_ksm().

Under heavy memory pressure, workloads that frequently split large VMAs can generate significant lock contention.

Examples include:

  • JVM garbage-collection barriers using mprotect
  • Go runtime memory-management operations
  • MySQL page reclamation through madvise
  • PostgreSQL memory-management workloads

The previous implementation could produce worst-case lock-hold times approaching 705 ms, long enough to cause visible application stalls.

The optimization reduces the relevant lock-hold time dramatically:

Metric Before Fix After Fix
Worst-case lock hold 705 ms 1.44 ms average
Peak reported value 705 ms 1.67 ms
Improvement Baseline Hundreds-fold reduction

The change focuses on improving locking behavior during reverse-mapping walks associated with anonymous memory.

Xiaomi improves zsmalloc deallocation
#

Xiaomi engineer Wenchao Hao optimized lock contention around zs_free() in the zsmalloc allocator.

zsmalloc is particularly important for compressed-memory technologies such as zRAM and zswap.

The reported improvements include:

  • 1.83× faster concurrent memory deallocation on a Raspberry Pi 4B
  • 1.4× improvement on a 20-core Intel server

These changes are especially relevant to systems where compressed memory is used aggressively and allocator contention can become a source of latency.

🤖 Linus Torvalds Uses Gemini During Intel GPU Debugging
#

One of the more unusual developments in the Linux 7.3 cycle involved Linus Torvalds using Google’s Gemini AI during the investigation of an Intel Battlemage G21 GPU boot failure.

The eventual fix was remarkably small: a single function call changed from round_up() to round_down().

A one-character change with system-level consequences
#

The underlying issue was located in get_flat_ccs_offset() within the Intel Xe DRM driver.

An incorrect offset calculation caused allocated VRAM to be interpreted incorrectly, ultimately resulting in graphics memory-management failures during startup.

The final correction changed the rounding direction:

round_up()
round_down()

Although the final patch was tiny, identifying the root cause was considerably more complicated.

The investigation reportedly involved:

  • 24 temporary debugging patches
  • 18 system reboots
  • Extensive instrumentation
  • Iterative isolation of the graphics memory-management path

Torvalds credited Gemini with assisting in the creation of debugging instrumentation and parts of the commit-development process.

AI enters kernel debugging workflows
#

The episode illustrates a potentially important development in large-scale systems programming.

AI assistance is not replacing kernel debugging, but it can accelerate mechanical parts of the workflow, including:

  • Generating instrumentation
  • Constructing temporary diagnostic patches
  • Summarizing code paths
  • Exploring hypotheses
  • Preparing commit messages
  • Automating repetitive debugging tasks

The key requirement remains expert validation because kernel-level changes can introduce subtle concurrency, memory-safety, and hardware-interaction failures.

🧠 Memory Management Development Accelerates
#

Linux memory management remains one of the busiest areas of kernel development.

MM maintainer Andrew Morton reportedly received approximately 1,250 memory-management patches during this cycle, representing an increase of roughly 330 patches over the previous cycle.

The volume reflects the increasing complexity of modern Linux workloads.

Memory management now has to accommodate:

  • Large multicore systems
  • NUMA architectures
  • Compressed memory
  • Virtual machines
  • High-performance storage
  • AI accelerators
  • Heterogeneous memory
  • Extremely large application address spaces

The resulting kernel work increasingly focuses on reducing contention and improving scalability rather than simply optimizing average-case throughput.

🧩 sched_ext Moves Beyond Experimental Status
#

Linux’s sched_ext BPF scheduler framework is another major architectural development in the 7.3 cycle.

The framework allows scheduling policies to be implemented using eBPF, providing substantially more flexibility than traditional statically compiled scheduler logic.

One important capability allows root-level schedulers to delegate cgroup subtrees to nested BPF schedulers.

This enables more dynamic control over CPU scheduling and resource allocation.

Dynamic scheduling policies
#

The architecture can be useful for environments requiring workload-specific scheduling behavior, including:

  • Cloud infrastructure
  • Container clusters
  • Gaming systems
  • Latency-sensitive services
  • Specialized compute workloads
  • Experimental scheduling research

Moving sched_ext beyond its experimental phase would represent a significant step toward making programmable scheduling a practical Linux subsystem.

🔗 AMD UALink Support Targets AI Clusters #

Linux 7.3 also includes substantial work supporting AMD UALink, with approximately 95 patches contributing to the initial implementation.

UALink is designed to provide high-bandwidth communication between accelerators within AI and HPC systems.

The proposed architecture can scale to domains containing up to 1,024 accelerator nodes, with support for direct remote-memory access between devices.

This is particularly important as AI systems move from individual accelerators toward large accelerator fabrics.

Why accelerator interconnects matter
#

AI performance increasingly depends not only on accelerator compute capability but also on how efficiently accelerators exchange:

  • Model parameters
  • Activations
  • Gradients
  • Intermediate tensors
  • Distributed memory

High-bandwidth accelerator interconnects therefore form an increasingly important layer of AI infrastructure.

Linux support is essential for exposing these capabilities to system software, runtimes, and distributed computing frameworks.

🍎 Apple Silicon Support Expands
#

The Linux kernel continues expanding upstream support for Apple’s custom silicon.

Linux 7.3 includes initial Device Tree support for Apple M3 Pro, M3 Max, and M3 Ultra processors.

This work contributes to the broader Asahi Linux effort to provide increasingly complete upstream Linux support for Apple Silicon systems.

Device Tree support is foundational because it allows the kernel to understand platform-specific hardware topology and configuration.

As more low-level platform components move upstream, running Linux natively on Apple hardware becomes progressively more practical.

🦀 Rust Support Expands on PowerPC
#

The Linux kernel’s Rust infrastructure is also expanding to additional CPU architectures.

The 7.3 cycle adds support for PPC32BE and PPC64LE to the kernel Rust toolchain.

This is significant because Linux’s adoption of Rust depends not only on language integration but also on making the toolchain available across the kernel’s diverse architecture ecosystem.

Broader architecture support creates more opportunities to use Rust for memory-sensitive kernel components while retaining compatibility with existing C code.

🛡️ NTFS3 Security and Reliability Refactoring
#

The NTFS3 filesystem driver receives additional security-focused work during the 7.3 cycle.

The changes address several classes of issues, including:

  • Slab out-of-bounds reads
  • Slab out-of-bounds writes
  • Integer-overflow conditions
  • NTFS Alternate Data Stream handling

Native parsing support for NTFS Alternate Data Streams (ADS) also expands the driver’s filesystem functionality.

Filesystem code is particularly sensitive to memory-safety errors because it processes complex, potentially untrusted on-disk structures.

The combination of security hardening and feature development is therefore important for maintaining NTFS3 as a production filesystem driver.

💾 Btrfs and EXT4 Performance Improvements
#

Storage performance is another major focus of Linux 7.3.

Btrfs direct I/O
#

Btrfs direct I/O is being converted to use iomap bounce buffers.

The reported improvement increases throughput efficiency from approximately 50% to 95% in the relevant testing scenario.

The change brings Btrfs closer to the highly optimized I/O infrastructure already used by other Linux filesystems.

EXT4 parallel direct writes
#

EXT4 is also receiving changes that allow greater parallelism for direct writes.

In reported NVMe testing, IOPS increased from approximately:

  • 1.92 million IOPS
  • to 2.19 million IOPS

This represents an improvement of roughly 14% in the tested workload.

The change is particularly relevant to high-performance NVMe systems where filesystem serialization can otherwise prevent storage hardware from reaching its potential.

🖥️ Hybrid CPUs and Legacy Hardware
#

Linux 7.3 also contains scheduler work targeting both modern hybrid processors and older hardware configurations.

Intel’s heterogeneous CPU architectures combine high-performance P-cores with efficiency-oriented E-cores, creating additional scheduling complexity.

The kernel must account for differences in:

  • Core performance
  • Frequency behavior
  • Power efficiency
  • Thread placement
  • Workload characteristics

At the other end of the hardware spectrum, scheduler changes are also being explored for legacy systems.

One example involves a single-runqueue scheduling model aimed at improving frame pacing on configurations such as Sandy Bridge CPUs paired with Radeon RX 580 GPUs.

This illustrates an ongoing Linux design challenge: supporting new heterogeneous hardware while continuing to optimize systems that remain widely deployed.

📅 Linux 7.3 Release Outlook
#

Linux 7.3 is expected to enter its release-candidate phase after the merge window closes, followed by several weeks of stabilization and regression testing.

The projected timeline is:

Milestone Expected Availability
Linux 7.3-rc1 Around August 30, 2026
Linux 7.3 GA Around late October 2026
Distribution Backports Dependent on individual distributions

Whether Linux 7.3 ultimately becomes a designated Long-Term Support (LTS) kernel depends on the kernel project’s subsequent maintenance decisions and release planning.

If selected, many of the cycle’s scheduler, memory-management, filesystem, architecture, and hardware changes could eventually reach enterprise distributions through their respective LTS maintenance branches.

🔍 Why Linux 7.3 Matters
#

The Linux 7.3 merge window demonstrates how kernel development is increasingly driven by real production constraints.

The most consequential optimizations are not necessarily large architectural rewrites. Some of the biggest gains come from eliminating pathological behavior under concurrency, reducing lock hold times, improving scheduler responsiveness, and removing serialization from high-throughput I/O paths.

At the same time, Linux is becoming a more important software foundation for AI infrastructure through technologies such as UALink, programmable BPF scheduling, and increasingly sophisticated accelerator support.

The cycle also highlights a changing development workflow in which AI tools can assist experienced kernel developers with debugging and code-generation tasks.

Taken together, these changes reinforce Linux’s role as the systems layer connecting increasingly heterogeneous CPUs, GPUs, accelerators, memory subsystems, and high-speed storage.

Related

Linux 7.2-rc1 Introduces a 43M-Line Kernel as Reserved THP RFC Emerges
·1151 words·6 mins
Linux Kernel Memory Management Transparent Huge Pages HugeTLB Open Source Kernel Development Performance Systems Programming
Linux 7.2 Removes strncpy After 37 Years of C Safety Debt
·1405 words·7 mins
Linux C Programming Rust Kernel Development Memory Safety Systems Programming Open Source Software Security Linux Kernel
Understanding the Linux Kernel (3rd Edition): Complete Guide
·1033 words·5 mins
Linux Linux Kernel Kernel Development Operating-Systems System Programming VFS Memory Management Kernel Architecture