Linux 7.3 Ships as Torvalds' Claude Code Patch Hits Review

Linux 7.3 Ships as Torvalds’ Claude Code Patch Hits Review

Linux 7.3 was released on October 18, 2026, following seven release candidates and arriving on schedule. The stable release includes hardware-enablement work, graphics improvements, and several memory-management optimizations.

Yet one of the most consequential Linux kernel stories surrounding this release is not a feature that shipped with Linux 7.3. It is an experimental patch series developed by Linux creator Linus Torvalds with assistance from Anthropic’s Claude Code.

The patches target a long-standing bottleneck in the Linux page cache. In a synthetic benchmark involving 64 threads on a Threadripper system, a revised version of the proposed optimization reportedly increased read throughput from 13.3 million to 304 million operations per second, an improvement of approximately 23 times.

The results are promising, but the patch series remains a work in progress. Reviewers identified a race condition involving file contents and file-size changes, while the proposed memory-reclamation mechanism introduces its own resource-management challenges.

The episode illustrates an important distinction in AI-assisted systems programming: AI can help developers explore complex optimizations, but substantial performance gains do not eliminate the need for rigorous testing, review, and integration work.

🚀 1. Linux 7.3 Arrives with a Record-Breaking Development Cycle

#

Torvalds announced the final Linux 7.3 release on October 18. In his release announcement, he said that the final development week had been relatively uneventful and that the Linux 7.4 merge window would open the following day.

He also noted that he was beginning his annual family vacation, meaning that his work on incoming merges would temporarily follow an unusual schedule.

Clarifying the commit count

#

The scale of Linux 7.3’s development cycle has attracted attention. According to LWN’s release summary, the cycle included:

These figures describe the overall development cycle, not just the initial merge window. LWN characterized the release as a record-breaker, so the more specific total of 18,765 non-merge commits provides useful context beyond the frequently repeated claim that the cycle contained more than 15,000 commits.

Another source of unusually large code changes was AMD’s DCN 6.0 display hardware. Torvalds criticized the practice of adding extensive hardware register definitions as C header files, pointing out how such definitions can inflate a patch’s size without representing an equivalent amount of new executable logic.

The broader lesson is that raw source-code volume does not necessarily measure a kernel release’s functional complexity. Hardware descriptions, generated definitions, tests, and documentation can contribute substantially to the diff.

Notable changes in Linux 7.3

#

Linux 7.3 includes a broad collection of hardware and performance improvements:

• AMD platform support: Continued preparations for Zen 6 processors, including updates to platform-management support.
• Intel graphics: Intel Xe3P graphics associated with Nova Lake are considered stable and enabled by default in the relevant kernel configuration.
• RISC-V: Additional instruction-set extension support expands the architecture’s hardware enablement.
• Apple Silicon: Early support for Apple M3 Pro, Max, and Ultra systems advances Linux bring-up work, although the initial support is not necessarily ready for everyday users.
• Gaming hardware: The kernel adds initial driver support for the 2026 Steam Controller.
• Older Radeon GPUs: Improvements to GPU reset recovery and graphics memory management benefit systems with older or resource-constrained hardware.

These changes are part of the released kernel. Torvalds’ Claude Code-assisted page-cache optimization, by contrast, is an experimental branch and should not be treated as a Linux 7.3 feature.

For a broader overview of the release, see Phoronix’s Linux 7.3 feature summary.

🎮 2. Three Practical Performance Improvements

#

Beyond hardware enablement, Linux 7.3 incorporates several changes aimed at reducing performance bottlenecks in graphics and memory management.

2.1 Valve improves GPU reset recovery and VRAM management

#

Valve’s Linux graphics engineers contributed improvements for older AMD Radeon GPUs, together with changes aimed at systems with limited graphics memory.

GPU reset recovery is especially important after a graphics fault. On affected legacy hardware, a reset could disrupt graphics memory contents and require applications to recover from lost resources. The new work improves reset handling and helps preserve usable graphics state where supported by the hardware and driver.

A separate memory-management improvement addresses systems whose GPUs have less VRAM than demanding games would ideally require. When graphics memory becomes scarce, the kernel can evict less-essential graphics data to system memory, leaving more local VRAM available for active workloads.

In testing cited during Linux 7.3 development, Indiana Jones and the Great Circle, reported to request around 9GB of VRAM, ran at playable frame rates on a GPU equipped with 8GB.

That is a workload-specific result, not a guarantee that every game requesting more VRAM than a GPU possesses will run smoothly. Performance still depends on memory-transfer costs, driver behavior, system RAM, and the game’s workload.

The changes are particularly relevant to older graphics cards and lower-cost gaming systems, where VRAM capacity can become a significant limitation.

2.2 ZTE reduces long KSM lock stalls

#

Kernel Samepage Merging (KSM) identifies identical memory pages and allows them to share physical storage. This can reduce memory consumption on systems running similar virtual machines or workloads.

However, when large numbers of memory mappings reference shared pages, the kernel’s reverse-mapping operations can become expensive.

Engineers at ZTE optimized rmap_walk_ksm(), which walks the mappings associated with pages managed by KSM. In a pathological stress-test scenario, the reported worst-case lock-hold time dropped from 705 milliseconds to 1.67 milliseconds.

That is a substantial reduction in the time other work may have to wait for the relevant lock. It should not be interpreted as a universal reduction in application latency: the figures describe a specific high-contention test case.

The change is relevant to virtualized and memory-intensive workloads where long lock holds can cause noticeable pauses.

2.3 Xiaomi reduces zsmalloc lock contention

#

The zsmalloc allocator is used by zRAM and Zswap to manage compressed memory. Its deallocation path can become a contention point when multiple CPUs free compressed-memory objects concurrently.

Engineer Wenchao Hao at Xiaomi developed a series of changes to reduce locking overhead in zs_free().

Reported benchmarks showed the following maximum improvements:

These figures come from specific concurrent memory-management workloads rather than general-purpose application benchmarks. The larger result on the Raspberry Pi demonstrates how removing lock contention can help constrained systems, but it does not imply that all zRAM or Zswap workloads will become almost twice as fast.

The changes illustrate a recurring theme in Linux 7.3: performance improvements often come from removing coordination costs inside the kernel rather than increasing raw hardware capability.

🧠 3. The Page-Cache Bottleneck Behind Torvalds’ AI-Assisted Patch

#

The most prominent AI-related development concerns the Linux page cache, which retains recently accessed file data in memory to avoid repeatedly reading it from storage.

When several threads read the same cached file concurrently, the kernel must ensure that the memory containing the cached data remains valid while each read is in progress.

The existing implementation uses folio reference counting to manage the lifetime of cached memory. A folio is the kernel’s memory-management abstraction for one or more physically contiguous pages.

During a read, the kernel obtains a reference to the relevant folio and subsequently releases it. These operations are normally inexpensive, but they can become a bottleneck when many CPU cores repeatedly update the same reference counter.

Why a small read can create a large bottleneck

#

The problem was identified by Oracle engineer Matthew Wilcox in 2024 while investigating a customer workload.

In Torvalds’ test on a Core i7-8565U laptop, eight threads repeatedly performed 16-byte pread() operations on the same cached page.

The test found that the cache line associated with the folio reference counter accounted for 99.92% of the load HITM events reported by perf c2c. HITM, or Hit Modified, events help identify cache-line transfers involving modified data between CPU cores.

The underlying problem was not that the file was large or that the storage device was slow. The bottleneck was the repeated modification of shared bookkeeping data.

Every thread needed to update the reference count, forcing CPU cores to contend over a cache line that was touched on nearly every read.

For a workload performing repeated small reads from the same file, the overhead of protecting the cached data could therefore dominate the operation itself.

From debugging assistance to AI-generated implementation

#

Rather than continuing to use AI only to analyze the problem, Torvalds used Claude Code to help develop an implementation and its associated test programs.

The resulting branch was named:

noref-filemap-read-with-llm

In the patch-series description, Torvalds explicitly credited the coding assistant with helping produce the code, tests, review material, and an initial draft of the patch description under his direction. He also clarified that he ran the measurements on his own hardware.

This was a notable example of AI being used in a low-level kernel optimization by an experienced maintainer. It was not, however, a case of an AI system independently producing and shipping a kernel change: Torvalds directed the work, evaluated the results, and submitted the experimental implementation for review.

⚡ 4. The Reported Performance Gains: 3× First, Then 23×

#

The performance story has two distinct sets of measurements. They come from different revisions of the patch and different test systems, so the figures should not be combined as though they describe the same experiment.

Initial eight-patch series: roughly 3× on a laptop

#

The first series targeted small reads from a shared cached page. On Torvalds’ four-core, eight-thread Core i7-8565U laptop, eight threads repeatedly read 16 bytes from the same one-page file.

The reported results were:

The throughput increase was about three times, while the measured load HITM events fell dramatically.

The improvement came from reducing the need to modify the shared reference-count cache line during the read path.

The result was meaningful for that particular microbenchmark, but it did not establish a threefold speedup for ordinary desktop, server, or database workloads. The benchmark was deliberately designed to stress the shared-cache-line bottleneck.

Revised series: approximately 23× on a Threadripper system

#

The later version changed the implementation and expanded the patch series. In a reported test using 64 threads on a Threadripper system, throughput increased from 13.3 million to 304 million reads per second.

That represents an approximately 22.9× improvement, often rounded to 23×. The reported kernel cycles per read also fell from nearly 20,000 to approximately 735.

The initial laptop result and the revised Threadripper result are not contradictory. They reflect different hardware, different contention levels, and different versions of the implementation.

The larger number is also not evidence that Linux as a whole became 23 times faster. It measures a narrowly targeted synthetic workload whose original execution path was dominated by folio-reference contention.

Torvalds’ own patch description emphasized that real-world gains would be much smaller than the most dramatic microbenchmark result suggests.

🔬 5. How the Proposed Optimization Works

#

The central idea is to avoid updating the folio reference count for every eligible small read while ensuring that the underlying memory cannot be reclaimed and reused too early.

The revised approach introduces a page flag named PG_rcu_free and uses Read-Copy-Update (RCU) mechanisms to defer final memory reclamation.

RCU is a synchronization technique used by the Linux kernel to allow readers to access data with relatively low overhead while ensuring that memory is not reclaimed until existing readers have finished.

Delaying reclamation rather than incrementing the reference count

#

Under the proposed design, a folio removed from the page cache is not immediately returned to the page allocator when its final reference disappears. Instead, the memory is retained until the required RCU grace period has elapsed.

The purpose is to allow a lockless reader that found the folio while holding an RCU read-side lock to finish accessing its contents before the memory can be reused for something else.

That changes the read path’s cost structure:

1. The reader looks up the cached folio while holding the relevant RCU protection.
2. It verifies the conditions required to use the cached data.
3. It copies the data into the user buffer without taking and releasing a folio reference for each eligible read.
4. Removed folios are reclaimed later, after the relevant readers have had an opportunity to finish.

This is not simply a matter of deleting reference-count operations. The kernel must also preserve the rules governing concurrent writes, page-cache replacement, truncation, migration, user-space memory faults, and memory reclamation.

The patch series therefore touches several parts of the memory-management system rather than changing only one function.

Technical details are documented in the experimental kernel branch.

The cost of deferring memory reclamation

#

Waiting for an RCU grace period keeps removed folios in memory for longer before they can be reused. Under heavy memory pressure, a large number of deferred pages could consume a significant amount of physical memory.

The proposed implementation includes safeguards intended to limit that problem. For example, when a CPU’s queue of deferred pages exceeds 1,024 pages, the code can trigger accelerated grace-period processing.

However, the branch’s own description acknowledges that the allocator cannot fully account for all pages awaiting deferred reclamation. Consequently, the memory manager may behave as though less memory is available than will eventually become free.

The design notes also describe potential problems involving reclaim, out-of-memory handling, and contiguous memory allocation. The queue threshold and accelerated reclamation help control the backlog, but they do not eliminate every concern.

These trade-offs are central to deciding whether the performance improvement is suitable for a general-purpose kernel.

🛑 6. Code Review Finds a Race Condition

#

The performance figures attracted attention, but the patch series also encountered a significant correctness issue during review.

Kiryl Shutsemau identified a race condition in filemap_read_rcu_batch() involving page-cache replacement and changes to a file’s size.

In the problematic sequence, a reader could find one folio, after which another operation removed or replaced that folio and extended the file’s i_size. If the timing of the checks was incorrect, the reader could potentially copy stale data from the old folio even though the corresponding contents had not been written to the file.

The problem was not merely a performance regression. It concerned the correctness of the data delivered to user space.

Why the race matters

#

A high-throughput read path must preserve the same file-data guarantees as the existing implementation. Avoiding reference-count updates is useful only if the kernel can still establish that the data being copied is valid and belongs to the expected file contents.

That requires careful ordering among:

• Page-cache lookups.
• Folio validity and uptodate checks.
• File-size reads.
• Page-cache replacement and removal.
• Memory reclamation after an RCU grace period.
• Copies from kernel memory into user-space buffers.

The review discussion examined how the i_size check and folio validation could be ordered to prevent the race. It also considered whether the newly introduced PG_rcu_free flag was the right way to represent the reclamation state.

The work moves to further review

#

Shutsemau proposed changes to address the race and subsequently took over further development of the series. The implementation remained under review rather than being accepted directly into the mainline kernel.

This is why describing the episode as an AI-generated optimization that immediately shipped with a 23× improvement would be misleading. The benchmark demonstrated potential, but code review still had to establish that the design preserved kernel correctness and behaved safely under memory pressure.

The review process did not invalidate the benchmark. It established that the implementation needed further engineering before the result could be considered for general use.

🤝 7. Linux’s Changing Policy on AI-Assisted Contributions

#

The patch appeared during a wider discussion about how the Linux kernel community should handle AI-generated or AI-assisted code.

At the October 8, 2026, Maintainers Summit in Prague, maintainers reportedly reached a consensus to remove the requirement for an Assisted-by tag identifying the use of AI tools. A related documentation patch was then circulated.

The earlier policy required patches developed partly or entirely with an LLM to carry an attribution tag. The intention was to make AI involvement visible to reviewers and provide a record of the tools used to produce code.

However, maintainers questioned whether the tag was achieving that goal. If AI assistance was already widespread and disclosure inconsistent, the absence of a tag could not reliably establish that a patch had been written without AI.

The discussion reflected different priorities. Some developers wanted AI-generated work to remain identifiable because that information could influence how they reviewed code. Others argued that the quality of the implementation mattered more than whether the contributor used a particular tool.

Torvalds has argued against banning AI tools from kernel development, comparing such restrictions to banning text editors. His position does not imply that AI-generated code should receive preferential treatment.

The page-cache episode illustrates the distinction: AI assistance helped explore a substantial optimization, but the same technical review process exposed a race condition and identified unresolved memory-management concerns.

Source: Phoronix coverage of the proposed Assisted-by policy change.

The policy debate concerns disclosure requirements. It does not remove the need for authors to understand their changes, respond to review, and provide evidence that kernel code is safe and correct.

📦 8. Linux 7.3 Availability and Long-Term Support

#

Linux 7.3’s release does not mean every distribution immediately ships the final kernel.

Ubuntu 26.10, for example, shipped its release images with kernel package 7.3.0-9.9, based on Linux 7.3-rc6, because the final upstream release arrived after the distribution’s release-image freeze. The final upstream kernel can be adopted through subsequent package updates, subject to Ubuntu’s packaging and update process.

Rolling-release distributions generally have a shorter path to adopting new upstream kernel releases, while distributions with longer support cycles may continue using an earlier kernel with selected fixes backported.

See Ubuntu 26.10 release notes.

The long-term support designation for Linux 7.3 should also be treated separately from its stable release date. The opening of the Linux 7.4 merge window does not by itself establish which kernel version maintainers will select for long-term support.

Another development worth noting is that longtime kernel contributor Darrick Wong is stepping back after 23 years of Linux development. His recent change removed him from the remaining code-review responsibilities he had held for I/O mapping functionality.

✅ 9. What This Means for Linux Kernel Development

#

Linux 7.3 delivers practical improvements to hardware support, graphics recovery, VRAM management, and memory-allocation performance. Those changes are distinct from the experimental Claude Code-assisted page-cache work, which has not been merged into the release.

The proposed page-cache optimization nevertheless highlights an important opportunity for AI-assisted development. A capable coding assistant can help a skilled maintainer investigate a narrow performance bottleneck, generate an implementation, write tests, and explore approaches that would otherwise require substantial manual effort.

But the same example shows why benchmark gains are only one part of kernel engineering. The revised patch produced a striking result under a highly constrained workload, yet its correctness depended on subtle interactions among memory reclamation, page-cache replacement, and concurrent reads.

Three conclusions stand out:

1. Linux 7.3 improves several real-world subsystems. The GPU and memory-management changes offer practical benefits, although the magnitude depends on the workload and hardware.
2. The 23× result belongs to a synthetic benchmark. It measures a targeted contention problem, not an equivalent acceleration across the entire operating system.
3. AI-assisted development still requires rigorous review. The race condition identified in the proposed implementation demonstrates why performance tests alone cannot establish correctness.

The next milestone for Torvalds’ patch is not a bigger benchmark number. It is a design that maintains data integrity, manages deferred memory reclamation safely, and withstands the full scrutiny required for integration into the Linux kernel.