Intel's Linux Memory Hotplug Patch Removes a Zone-Wide Scan, and CXL Is Why It Matters

By Indie Kings | September 27, 2026

Updated September 27, 2026: Intel engineer Yuan Liu has landed a kernel change that cuts memory hotplug times by up to 81 percent for virtual machines and up to 75 percent for unplugging, by removing a page-block-by-page-block scan across an entire memory zone. The patches are queued for the Linux 7.4 merge window in October, so this is work in progress rather than shipped. It matters more than the headline figure suggests, because the operation being optimised is the one CXL depends on, and Samsung's own testing of hotplugging memory over CXL found the same improvements.

Verification note: Reported by Phoronix's Michael Larabel on September 27, 2026, from Yuan Liu's cover letter for the patch series and the benchmarks it carries, including results from Samsung. The patches are in the mm/core.git for-next branch and are expected to be submitted for the Linux 7.4 merge window in October. That is a submission, not a merge, and we have written it as queued work. The 81 and 75 percent figures are the best cases in the reported results rather than averages, and are attributed as such.

Benchmark results showing memory hotplug and hot unplug time reductions

Image: memory hotplug benchmark results. Credit: Phoronix / Intel.

What the operation actually is

Memory hotplugging is the ability to add or remove RAM from a running system without powering it off, and it is easy to underestimate how much infrastructure sits behind that sentence.

The Linux kernel's zone device abstraction is what makes it possible. Rather than treating all physical memory as one flat space, memory is organised into zones, and a zone device can describe a region of memory that is present, may be added, or may go away. When you ask the system to add a CXL memory device, or to grow a virtual machine's allocation, the kernel has to find a physically contiguous range large enough to back the new memory, because a mapping of scattered pages is not sufficient for the memory manager's purposes.

So the operation is a search. Given a size request and a zone, the kernel has to establish whether the zone contains a large enough contiguous span, and if so where it is. That search is what has been optimised.

Why the scan was slow

The fix is small and the description of the problem is more useful than the number that came out of it.

According to the cover letter, the work optimises zone contiguous checks by avoiding page block by page block scans across an entire zone.

Read literally, the previous approach walked the whole zone one page block at a time. The new one does not. That is the entire change in one sentence, and it is worth pausing on what it implies: the cost of the operation was proportional to the size of the entire memory zone rather than to the size of the request or to the size of the answer.

This is the shape of a genuine algorithmic finding rather than a micro-optimisation. A 5 percent faster loop, or a better cache behaviour in the same loop, does not produce an 81 percent reduction on the best case. Removing a scan whose length is unrelated to the work you are doing will. It also means the benefit should grow as systems get larger, because the old cost scaled with total memory while the new one does not.

The results, and what they mean

The reported figures are large, and they come with the context that makes them credible rather than suspicious.

Operation	Best reported change	Who measured it
Memory hotplug for a virtual machine	Up to 81 percent time reduction	Intel, in the patch series cover letter
Memory hot unplug	Up to 75 percent time reduction	Intel, in the patch series cover letter
Memory hotplug via CXL	Sizable improvements	Samsung, independent of the Intel series

Two qualifications belong with those numbers. They are best cases rather than averages, which is how a figure like this normally arrives and how it should be read. And the operation is asynchronous relative to everything else the kernel is doing, so a raw percentage understates the practical benefit for the workloads the series is aimed at, which are virtual machine memory growth and CXL device expansion.

The third row is the one that carries the most weight, and it is the reason this is not just an Intel story. Samsung tested hotplugging memory over CXL and found sizable improvements, independently of the series Intel submitted. That is a memory manufacturer confirming a kernel-side result on its own hardware, which is a much stronger signal than a vendor benchmark of its own patch.

Why CXL is the important part

The practical framing is that this work targets the case CXL exists to serve, and the series is not short on examples of where that matters.

CXL, Compute Express Link, is the interconnect that lets a system attach memory as a device rather than solder it on or put it in a DIMM slot. The pitch is straightforward: you can add memory to an existing machine without replacing what is there, at high capacity, without the pin count of a conventional memory interface.

Every one of those benefits assumes adding memory is a routine, fast operation. If the kernel takes a long time to find and set up a contiguous range, then the theoretical capacity advantage of CXL is real while the practical experience of adding a device is poor, and adoption stalls on kernel behaviour rather than on hardware. This series removes that objection on the setup path, which is the part users actually wait through.

It is also worth putting next to where memory prices have gone. We have covered desktop memory rising by hundreds of percent and laptop SO-DIMMs roughly sixfold, and the usual consequence people draw is that buying memory has become expensive. The other consequence is that adding memory becomes more valuable than it used to be, because a machine that can accept more later is a machine whose capacity decision is deferrable. CXL is the mechanism, and this patch series makes the mechanism faster. Whether that combination changes buying behaviour is not something we can predict, and we will not pretend otherwise.

Where this actually stands

Nothing here has shipped, and the timeline is specific.

The patches are queued in the for-next branch of mm/core.git, which is the staging branch for memory management changes bound for a merge window. The expected window is Linux 7.4, in October. The cover letter carries the technical detail, and both Intel's numbers and Samsung's CXL results are cited from it.

So the honest framing is that this is submitted work with reported results, on a reasonable timeline, from a named engineer at a company with a direct interest in the outcome. Linux merge windows do slip and patches do get revised or dropped, and an 81 percent figure in a cover letter is a best case produced by the party proposing the change rather than an independent audit.

What would make it more solid is simple to state: the series landing in a mainline release and the numbers holding up on other people's hardware. The Samsung result is a step in that direction and no more.

FAQ

What is being optimised in the Linux kernel?

Zone contiguous checks, which is the operation the kernel performs to locate a physically contiguous range of memory large enough to back newly added memory. The change avoids scanning the entire zone page block by page block, so the cost is no longer proportional to the total size of the zone.

How much faster is it?

Up to an 81 percent time reduction for memory hotplugging in a virtual machine, and up to 75 percent for memory hot unplugging. These are the best cases in the reported results rather than averages, and the operation is asynchronous relative to other kernel work, so the practical benefit for the targeted workloads is larger than the raw percentage suggests.

Who did the work and where does it stand?

Yuan Liu of Intel led the work. The patches are queued in the for-next branch of mm/core.git and are expected to be submitted for the Linux 7.4 merge window in October 2026. That is a submission, not a merge, so this is not yet in a mainline release.

What is CXL and why does it matter here?

Compute Express Link is an interconnect that lets a system attach memory as a device rather than through a memory slot, so capacity can be added to an existing machine. All of its benefits assume adding memory is quick, and if the kernel is slow to set up a new range then the capacity advantage is theoretical while the experience is poor. This work targets that setup path.

Was the result independently verified?

Partly. Samsung tested memory hotplugging over CXL and found sizable improvements, independently of the series Intel submitted, which is a memory manufacturer confirming a kernel-side result on its own hardware. The headline Intel figures come from the cover letter of the change itself and are best cases, so they have not been independently audited.

Why does a small code change produce a large speedup?

Because the old cost scaled with the total size of the memory zone rather than with the size of the request or the answer. Removing a scan whose length is unrelated to the work being done is a different class of fix from tightening a loop, and it should also scale better as systems get larger.

Bottom Line

The useful thing about this patch series is not the percentage, it is the shape of the bug. Intel engineer Yuan Liu optimised the zone contiguous check by stopping the kernel from scanning an entire memory zone one page block at a time, and the reported result is up to 81 percent less time for hotplugging memory into a virtual machine and up to 75 percent less for unplugging. A 5 percent faster loop does not produce that. A change that removes work whose cost was proportional to the total size of the zone rather than to the size of the request does, and it should hold up better on larger machines rather than worse. That is why this is worth more than a routine kernel performance item. The operation being fixed is exactly the one that adding CXL memory depends on, because CXL exists so you can attach memory as a device instead of putting it in a slot, and every benefit of that design assumes the kernel can set up a new contiguous range quickly. If it cannot, the capacity advantage is theoretical and adoption stalls on kernel behaviour rather than on hardware. So this removes a fairly mundane objection to a fairly important technology, and the third row of the results table is why we would not dismiss it as a vendor claim: Samsung tested memory hotplugging over CXL independently and found the same improvements, which is a memory manufacturer confirming a kernel result on its own silicon. The Intel figures themselves are best cases from the cover letter of the change being proposed, not averages and not an independent audit, and the patches are queued in mm/core.git's for-next branch awaiting the Linux 7.4 merge window in October, which means submitted rather than shipped. Merge windows slip and patches get revised, so the sensible position is that this is credible work on a reasonable timeline from a named engineer at a company with a stake in the result. The pairing with the memory market is worth one line rather than a paragraph. We have covered desktop memory rising by hundreds of percent and laptop SO-DIMMs roughly sixfold, and the reflex is that buying memory got expensive. The other consequence is that adding memory became more valuable, because a machine that can take more later defers the capacity decision. CXL is the mechanism for that, and this makes the mechanism faster. Whether the two together change what anyone buys is not something the numbers here can answer, and a kernel patch is a poor place to try. What it does answer is the question of whether the software side of adding memory is ready, and on this evidence it is closer than it was a month ago.

Source: Phoronix, Intel Delivers A Significant Memory Hotplugging Performance Optimization For Linux by Michael Larabel, September 27, 2026, reporting Yuan Liu's cover letter for the patch series queued in mm/core.git for-next, including Samsung's CXL hotplugging results