Linux 7.2-rc1 Introduces a 43M-Line Kernel as Reserved THP RFC Emerges
The release of Linux 7.2-rc1 marks another milestone in the evolution of the Linux kernel, with the codebase now exceeding 43 million lines of code. While the release itself follows a relatively typical merge window, a separate development has attracted considerable attention within the Linux community.
During the same week, ByteDance engineer Qi Zheng submitted a Request for Comments (RFC) to the Linux Kernel Mailing List (LKML) proposing Reserved THP (Transparent Huge Pages)—a new memory management approach designed to combine the deterministic allocation behavior of HugeTLB with the flexibility of Transparent Huge Pages.
If adopted, the proposal could address long-standing challenges encountered by hyperscale infrastructure operators running memory-intensive production workloads.
🐧 Linux 7.2-rc1 Continues Kernel Growth #
Linux continues to expand alongside modern hardware platforms.
Between Linux 7.1 and Linux 7.2-rc1, the kernel grew by approximately 970,000 lines of code, bringing the total codebase to nearly 43.9 million lines.
According to Linus Torvalds, the development cycle was largely routine despite the significant amount of new code merged.
Several notable changes contributed to the release.
Expanding Hardware Support #
The largest contributor to code growth remains hardware enablement.
In particular, the AMDGPU and AMDKFD subsystems continue to expand as AMD introduces new GPU architectures.
A significant portion of the merge window consisted of:
- GPU register definitions
- Device support updates
- Driver enhancements
- Hardware initialization improvements
This trend reflects the increasing complexity of modern graphics and accelerator hardware.
Eliminating Legacy Technical Debt #
Kernel development also continues to emphasize long-term maintainability.
One notable milestone is the complete removal of the legacy strncpy() API after years of gradual refactoring.
The replacement of this historically error-prone interface with safer string handling functions improves code quality and reduces potential security risks across numerous kernel subsystems.
Linux 7.2-rc1 also removes several obsolete drivers that no longer serve active hardware platforms, continuing the kernel’s ongoing cleanup effort.
💾 Understanding Linux Huge Page Management #
The Reserved THP proposal focuses on one of Linux’s most performance-critical subsystems: huge page memory management.
Large-memory workloads often benefit from huge pages because they reduce Translation Lookaside Buffer (TLB) pressure and improve memory access efficiency.
Linux currently provides two primary mechanisms.
HugeTLB #
HugeTLB uses statically reserved huge pages allocated during system boot.
Characteristics include:
- Guaranteed allocation
- Physically contiguous memory
- Very low allocation latency
- Reduced TLB misses
Applications such as databases, Java virtual machines, and high-performance computing workloads frequently rely on HugeTLB.
However, these benefits come with several limitations:
- Memory must be reserved in advance
- Reserved pages cannot be used by other applications
- HugeTLB pages cannot be swapped
- Reserved memory may remain unused
Transparent Huge Pages (THP) #
Transparent Huge Pages take a different approach.
Instead of requiring explicit reservation, the kernel dynamically promotes standard 4 KB pages into larger pages whenever possible.
Advantages include:
- Automatic operation
- No application modifications
- Better memory utilization
- Native swap support
However, THP also has trade-offs.
Successful allocation depends on the availability of contiguous physical memory.
On heavily fragmented systems, allocation success rates decrease, while background page compaction and khugepaged activity may introduce additional latency.
⚠️ Production Challenges at Hyperscale #
The Reserved THP proposal is motivated by production issues observed in large-scale infrastructure environments.
One example involves hot upgrades, where two versions of an application temporarily coexist during zero-downtime deployments.
Consider a service using a 16 GB HugeTLB pool.
During deployment:
- The existing application continues running.
- A new instance starts simultaneously.
- Both instances require dedicated huge page allocations.
This temporarily doubles huge page requirements from 16 GB to 32 GB.
After the upgrade completes, much of the reserved memory becomes unused, yet remains unavailable for general system allocation.
An additional complication arises because inactive HugeTLB pages cannot be swapped to disk.
As a result, systems may encounter memory pressure even when a significant portion of allocated memory is effectively idle.
Transparent Huge Pages avoid this limitation through swap support but cannot guarantee successful huge page allocation under fragmented memory conditions.
🚀 Reserved THP: A Hybrid Approach #
Reserved THP attempts to combine the strengths of both existing mechanisms while minimizing their respective drawbacks.
Feature Comparison #
| Capability | HugeTLB | Transparent Huge Pages | Reserved THP |
|---|---|---|---|
| Allocation | Boot-time reservation | Dynamic allocation | Boot-time reservation |
| Guaranteed Availability | Yes | No | Yes |
| Swap Support | No | Yes | Yes |
| Fragmentation Resistance | High | Lower | High |
The objective is to preserve deterministic huge page allocation while retaining the flexibility of the THP subsystem.
⚙️ How Reserved THP Works #
Under the proposed design, the kernel reserves a physically contiguous memory region during boot.
Unlike HugeTLB, however, this memory is managed internally by the Transparent Huge Pages subsystem.
Applications explicitly request pages from the reserved pool through madvise().
Key characteristics include:
- Boot-time reservation
- Exclusive allocation for designated applications
- Transparent Huge Page management
- Native swap capability
- Isolation from normal memory allocation
Because Reserved THP inherits THP’s paging infrastructure, inactive huge pages may be swapped to secondary storage when appropriate.
According to production estimates cited in the proposal, this approach could reduce temporary memory consumption during hot upgrades from approximately 32 GB to 22 GB, substantially improving resource utilization.
📨 Current Status #
Reserved THP remains an RFC (Request for Comments) rather than an accepted kernel feature.
At this stage, the Linux community is evaluating:
- Design correctness
- API compatibility
- Long-term maintainability
- Interaction with existing memory management
- Performance implications
Discussion within the Linux Kernel Mailing List will ultimately determine whether the proposal evolves into an upstream feature.
Regardless of the outcome, the RFC contributes valuable production experience from hyperscale deployments to the broader Linux ecosystem.
🌍 The Importance of Upstream Contributions #
One notable aspect of the proposal is ByteDance’s decision to submit the work directly to the upstream Linux kernel.
Large technology companies increasingly recognize that maintaining extensive private kernel modifications creates substantial long-term engineering costs.
Private forks require continuous effort to:
- Rebase onto new kernel releases
- Resolve merge conflicts
- Maintain compatibility
- Backport security fixes
By contributing improvements upstream, organizations distribute maintenance across the broader open-source community while ensuring long-term compatibility with future kernel releases.
This collaborative model has previously benefited from significant contributions across the industry, including new filesystems, networking enhancements, scheduler improvements, and memory management innovations developed within hyperscale production environments.
🔍 Outlook #
The release of Linux 7.2-rc1 demonstrates the continued expansion of the Linux kernel as it adapts to increasingly sophisticated hardware platforms while simultaneously improving maintainability through long-term code cleanup.
Meanwhile, the Reserved THP proposal highlights a different aspect of kernel evolution: adapting foundational memory management mechanisms to the realities of modern hyperscale infrastructure.
By combining deterministic huge page allocation with Transparent Huge Pages’ flexibility and swap support, Reserved THP aims to address practical deployment challenges that neither HugeTLB nor THP fully solve independently.
Whether or not the RFC ultimately becomes part of the upstream kernel, it illustrates how large-scale production environments continue to shape the evolution of Linux through real-world operational experience and open-source collaboration.