Two LLM-assisted memory-management patch sets [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Two LLM-assisted memory-management patch sets
Ready to give LWN a try?
With a subscription to LWN, you can stay current with what is happening in the Linux and free-software community and take advantage of subscriber-only site features. We are pleased to offer you a free trial subscription , no credit card required, so that you can see for yourself. Please, join us!
By Jonathan Corbet<br>July 2, 2026
The kernel community (like many other free-software projects) has recently<br>seen a large influx of patches developed with the assistance of large<br>language models (LLMs). Those patches tend to come from developers who<br>were previously unknown to the community. At the moment, though, the<br>memory-management developers are evaluating two large patch sets, developed<br>with LLM assistance, that were submitted by established and well-respected<br>developers. The rather different reception accorded to that work may give<br>insights into how LLM-generated contributions will be handled going<br>forward.
Reliable 1GB allocations
As a Linux system runs, it tends to fragment its memory, making the<br>allocation of large, physically contiguous chunks of memory difficult.<br>Much work has been done over the years to improve this situation; the<br>kernel tries hard to avoid fragmentation, and to actively defragment memory<br>as needed. Larger allocations are more reliable than they once were.<br>Still, allocation challenges can, for example, make it harder for the<br>system to provide 2MB PMD-level huge pages than would be ideal.
Given that difficulty, it might seem that reliable allocation of PUD-level<br>(1GB) huge pages is an impossible goal. But, as Rik van Riel said in the<br>cover<br>letter to a 40-part patch series, there are workloads that can gain<br>significant performance benefit from the use of 1GB huge pages, if they can<br>succeed in obtaining them. The only way to reliably allocate regions of<br>that size in current kernels is to use the hugetlbfs<br>subsystem, which reserves memory for this purpose at boot time. Hugetlbfs<br>is inflexible, though; its reserved pages cannot be used for other<br>purposes, and it cannot reserve additional pages if the workload needs<br>them. The system administrator can only hope that the reservation set up<br>at boot time is suitable for all workloads the system may subsequently run.
Van Riel's patch set attempts to make 1GB allocations more reliable without<br>the need for the hugetlbfs reservation. It takes a number of approaches to<br>reach that goal, but the core idea is the management of memory in units<br>known as "super page blocks". The kernel breaks memory into page blocks<br>now, and it manages them in ways designed to combat fragmentation. One of<br>the key techniques is to segregate allocations that can be moved from those<br>that cannot. For example, most user-space memory is movable, it is just a<br>matter of changing all of the relevant page-table entries to match. On the<br>other hand, allocations for the kernel's own use generally cannot be moved.<br>By keeping the two types separate, the kernel maximizes its chances of<br>creating entire free page blocks by moving the pages within them elsewhere.
Page blocks work reasonably well when it comes to helping the page<br>allocator provide PMD-level huge pages. But they are much smaller than the<br>1GB target that Van Riel is trying to hit; on the system used to write this<br>article, page blocks are configured to be 4MB in size. In a typical<br>system, some page blocks will be used for movable allocations, while others<br>will hold unmovable allocations. The movable blocks can, at need, be<br>emptied out to create more PMD-level huge pages. But it only takes a<br>single unmovable page block to render its entire containing 1GB huge page<br>unmovable and, as a result, permanently fragmented.
The addition of super page blocks gives the page allocator another level of<br>visibility into the use of memory. If a request comes in to allocate an<br>unmovable page, the allocator will attempt to allocate from an unmovable<br>page block as before. Should there be no such page blocks with free memory<br>available, though, the allocator will need to pick a new page block to<br>allocate from. Van Riel's patch set will cause the allocator to attempt to<br>select that page block from a super page block that already holds other<br>unmovable allocations. In other words, the segregation of movable and<br>unmovable allocations is now done at the 1GB scale, increasing the chances<br>that 1GB huge pages can be created and allocated at need.
There are a number of other techniques that are employed to help this<br>overall policy succeed. Consider, for example, a virtually mapped<br>kernel-space allocation (as might be obtained with kvmalloc())<br>requiring several pages. This allocation is not movable, and...