Two memory management changes merged for Linux 7.3 target the same problem from opposite ends: a lock held for far too long while the system is already under pressure. The first reduces contention inside zs_free, the free path of the zsmalloc allocator that zRAM and Zswap sit on top of, and was measured at up to 1.83 times faster on a Raspberry Pi 4B and up to 1.4 times on a twenty core Intel machine. The second rewrites the reverse mapping walk used by Kernel Samepage Merging, taking a worst case lock hold from 705 milliseconds down to 1.67 milliseconds. Reported on Wednesday, August nineteenth, 2026.
The short answer
Andrew Morton sent the memory management updates for the Linux 7.3 merge window, reported on Wednesday, August nineteenth, 2026. Reduced locking contention in the zsmalloc zs_free path, which zRAM and Zswap depend on, measured up to 1.83 times faster on a Raspberry Pi 4B and up to 1.4 times on a twenty core Intel system. Separately, ZTE engineers rewrote rmap_walk_ksm so lock hold times fall from over 500 milliseconds to under 2 milliseconds.
A 705 millisecond lock hold is not a performance problem. It is an outage that nobody logged, because from userspace it looks like the machine simply stopped for two thirds of a second and then carried on.
The two changes
Andrew Morton sent the memory management pull requests for the Linux 7.3 merge window, and reporting appeared on Wednesday, August nineteenth, 2026. Two items in that pull are worth reading closely if you run anything memory constrained.
The first reduces locking contention in zs_free. That function belongs to zsmalloc, the specialised allocator the kernel uses to pack compressed pages efficiently, and zsmalloc is what both zRAM and Zswap are built on. The contention was described as significant in the unmapping path when a system is under memory pressure, with Google Android devices and servers running Zswap heavy workloads called out as the affected cases.
The second targets rmap_walk_ksm, the reverse mapping walk for pages managed by Kernel Samepage Merging. ZTE engineers, with Xu Xin leading the work, described the existing behaviour as a severe performance problem in which applications can freeze for hundreds of milliseconds under memory pressure.
Different subsystems, identical failure mode. In both cases the kernel takes a lock, does an amount of work that grows with how loaded the machine is, and holds everyone else still while it finishes.
zsmalloc, and why the Raspberry Pi number is the interesting one
The benchmark from Wenchao Hao of Xiaomi is straightforward enough to picture. Processes map 256 MB, write data into it, call madvise to push those pages out through zRAM, then unmap concurrently. The concurrent unmap is the pressure: several CPUs arrive at zs_free at the same moment and queue behind each other.
On a Raspberry Pi 4B, the fix was worth up to a 1.83 times speedup. On a twenty core Intel system, up to 1.4 times.
Read those two figures together rather than taking the larger one. The small ARM board gains more, and that is exactly what you would expect from a lock contention fix, because slower cores spend proportionally longer inside the critical section and there is less headroom to absorb the wait. The twenty core machine has more CPUs contending but each one clears the lock faster.
The practical translation is that this change helps most on the hardware least able to defend itself. Edge nodes, small ARM boxes, memory constrained VMs, anything with zRAM configured as a way to survive on less RAM than the workload really wants. Those are the machines where a slow free path compounds, because the reason zRAM is enabled at all is that the system is expected to run near its limit.
KSM, and the stall that made people turn it off
Kernel Samepage Merging finds identical pages in memory and collapses them into one physical page shared by many mappings. On a KVM host running dozens of guests from the same base image, the savings are substantial, which is why KSM exists and why hypervisor operators keep reaching for it.
Sharing has a cost, and the cost lands in the reverse direction. Once a page is shared, the kernel sometimes needs to find every mapping that points at it, and rmap_walk_ksm is the function that does that walk. The more sharing you have achieved, the longer the walk.
The ZTE measurements make the pathology concrete. In the worst case they constructed, 20,000 virtual memory areas all shared a single anon_vma. Lock hold time in that case was 705 milliseconds at maximum. After the optimisation, the same case measured 1.67 milliseconds at maximum and 1.44 milliseconds on average. Stated more generally, lock hold times dropped from more than 500 milliseconds to under 2 milliseconds.
That is a factor of roughly four hundred, and it is the rare kernel number where the multiplier understates the effect. Half a second of frozen memory management does not degrade a workload gracefully. It times out a health check, it trips a leader election, it makes a database replica look dead to its peers. The consequences are discrete failures rather than a slightly worse percentile.
There is an operational note buried in this. If you have ever disabled KSM on a hypervisor because guests were freezing for reasons nobody could pin down, this is a plausible explanation for what you were seeing, and the trade that made you turn it off has changed. It is worth re-measuring on 7.3 rather than treating your old decision as settled.
Where this sits in the 7.3 cycle
Linux 7.3 is turning into a heavy cycle for the parts of the kernel that decide who waits and for how long. The scheduler side of the same merge window brought a cgroup scheduling rework that moves EEVDF onto a single runqueue, which attacks jitter in container workloads from the CPU direction while these two patches attack it from the memory direction.
The base for all of it is Linux 7.2, released in mid August 2026, so 7.3 is early in its cycle and a stable release is roughly two months away on the usual cadence.
Neither memory management change needs configuration. There is no new tunable, no new sysctl, and no behaviour to opt into. Upgrading is the entire action, which is the best kind of kernel fix and also the kind that quietly never gets credited when the stalls stop.
What to measure before you upgrade
If you run zRAM or Zswap, capture what unmapping looks like under pressure now. A simple version is to watch how long a memory heavy process takes to exit while the machine is swapping to zRAM, since teardown is where the free path gets hammered.
If you run KSM on a hypervisor, look for the stalls rather than for throughput. Guest side clock jumps, health check timeouts that cluster without an obvious cause, and hundred millisecond spikes in otherwise flat latency graphs are the fingerprints. A worst case that moves from 705 milliseconds to under 2 will show up in the tail of those graphs and nowhere else.
Both of these are worth writing down before the upgrade rather than after, because a fix this large is invisible in an average and obvious in a maximum, and nobody keeps maximums by accident.
Sources and further reading
- Two Very Exciting Memory Management Optimizations Going Into Linux 7.3, Phoronix, August 19, 2026
- zsmalloc, The Linux Kernel documentation
- Kernel Samepage Merging, The Linux Kernel documentation
- Linux 7.2 Released With Faster I/O, New AMD and Intel Driver Improvements, Phoronix, August 2026
Frequently asked questions
Which workloads actually touch the zsmalloc path?
Anything using zRAM or Zswap, which is a wider set of machines than most people assume. zsmalloc is the allocator that stores compressed pages, and zs_free is what runs when those compressed pages are released. The contention shows up in the unmapping path when a system is already under memory pressure, so the shape of the problem is a machine that is short on RAM getting slower precisely while it is trying to reclaim. Two named cases are Android devices, where zRAM is standard, and servers running Zswap heavy workloads. Container hosts that lean on zRAM instead of disk swap sit squarely in the second group.
What was measured, and on what hardware?
The benchmark had processes map 256 MB of memory, write data into it, call madvise to force the pages out through zRAM, then unmap concurrently. That final concurrent unmap is the part that hits zs_free from several CPUs at once. On a Raspberry Pi 4B the change was worth up to a 1.83 times speedup. On a twenty core Intel system it was worth up to 1.4 times. The gap between those two numbers is informative: a small ARM board with slow cores feels lock contention more sharply than a wide server, which is a useful reminder if your fleet includes edge hardware.
What is KSM and why did it stall for 705 milliseconds?
Kernel Samepage Merging deduplicates identical memory pages, which is why it is common on KVM hosts running many similar guests. Merging means one physical page is now referenced from many places, and rmap_walk_ksm is the function that walks those references backwards when the kernel needs to act on the page. ZTE engineers found that walk holding a lock for a very long time in the pathological case: 20,000 virtual memory areas all sharing a single anon_vma. The reported worst case was 705 milliseconds of lock hold. From the guest side that looks like the whole machine freezing for two thirds of a second.
Do I need to enable anything to get these fixes?
No. Both changes are inside existing code paths, so upgrading to Linux 7.3 is the whole action. Neither introduces a new tunable, and neither changes behaviour in a way that requires you to revisit your zRAM or KSM configuration. What does deserve a look is whether you turned KSM off at some point because of exactly this symptom. Plenty of KVM operators disabled page merging after chasing unexplained guest stalls, and the arithmetic that made KSM look like a bad trade may now come out differently on hosts with many similar guests.
When does Linux 7.3 actually ship?
The 7.3 merge window opened shortly after Linux 7.2 was released in mid August 2026, and a kernel cycle typically runs around two months from merge window to stable. That puts a 7.3 release in the second half of October 2026 on the usual cadence, with release candidates arriving weekly before then. Distributions that track mainline closely will have it sooner than enterprise distributions, which is the normal split. If either of these fixes matters to a production symptom you are chasing today, the release candidates are the earliest reasonable place to test, not the place to run.