Phoronix highlighted both series in Andrew Morton’s unusually large memory-management pull for the Linux 7.3 merge window. The underlying Linux kernel mailing-list threads support the substance of the report, but also add an important qualification: these are merge-window changes, not a Linux 7.3 release people can deploy today. Distribution kernels will not gain them until Linux 7.3 lands and individual vendors choose to ship or backport the work.
The first patch set comes from Xiaomi engineer Wenchao Hao and changes the zs_free() path in zsmalloc, the allocator used by zRAM and by Zswap’s compressed page cache. The second, from Xu Xin, repairs KSM’s reverse-mapping lookup so it searches the relevant virtual-memory area instead of effectively asking the kernel to consider the whole address space. Both are narrow code changes with unusually direct consequences for desktops, phones, virtual machines, containers, and servers that are trying to survive tight RAM conditions.
zsmalloc drops a lock from compressed-swap teardown
The zsmalloc work attacks a particular moment of contention: freeing compressed pages while processes are being unmapped. This can happen as Android kills memory-hungry processes, when a Linux server sheds memory under pressure, or when concurrent workloads release swap-backed mappings through zRAM or Zswap.
Today, zs_free() takes a pool-wide read lock simply to identify the zsmalloc size class associated with a compressed object. It then takes a size-class lock and may hold it while returning pages to the buddy allocator. The practical result is two queues forming at once: many CPUs bounce the shared pool-lock cache line while freeing compressed objects, and other frees in the same class wait if page release is delayed on the kernel’s zone lock.
Hao’s four-patch series changes the object encoding so a 64-bit kernel can identify the relevant size class directly from its opaque zsmalloc handle. It can therefore take the narrower class lock without first entering the pool-wide lock. The series also moves the potentially expensive zspage freeing operation outside the class lock.
The design is more conservative than a headline about “removing locking” suggests. The lockless class lookup applies where the handle has spare bits to encode the class index. On 32-bit builds, and on 64-bit configurations without those spare bits, the existing pool-lock lookup remains the fallback. That means the biggest claimed benefit is aimed at the mainstream 64-bit systems running zRAM or Zswap, rather than every Linux device indiscriminately.
Andrew Morton said he would add the v6 series to mm.git, the staging tree used for this part of the kernel. In the mailing-list discussion, the benchmark used a deliberately hostile sequence: each process mapped 256 MB, populated it, called madvise(MADV_PAGEOUT) to push data into zRAM using LZO-RLE compression, and then unmap operations ran concurrently.
On a four-core Raspberry Pi 4B, the multi-process test completed in 110.6 milliseconds with the patch, down from 202.9 ms—an improvement of 1.83 times. On a 20-core Intel Core i7-12700 system with 16 concurrent processes, the corresponding result fell from 63.0 ms to 45.3 ms, or 1.39 times faster. The single-process results were more modest: 1.05 times on the Pi and 1.19 times on Intel.
Those numbers point to the actual value of the patch. This is not a compression breakthrough, a higher zRAM ratio, or an across-the-board memory-speed upgrade. A machine that rarely swaps, has no compressed swap configured, or frees these mappings one process at a time should expect little or nothing. The improvement appears when several CPUs reach the same allocator bottlenecks at precisely the time applications are already vulnerable to pauses.
For Linux administrators, the affected configurations are identifiable. zRAM creates compressed RAM-backed block devices such as /dev/zram0, often configured as swap on memory-constrained machines. Zswap is different: it sits in front of a backing swap device and holds pages in a compressed RAM pool before they must go to disk. Kernel documentation confirms that Zswap uses zsmalloc to manage that pool. Consequently, a Zswap-heavy VM host and a compact laptop configured with zRAM swap can both benefit, even though their storage layouts and workload profiles differ.
The change does not justify turning on zRAM or Zswap without testing. Compressed swap exchanges CPU time for reduced swap I/O and uses RAM for its compressed pool; whether that is a win depends on the workload, available cores, compression algorithm, and the speed of the real swap device. Linux 7.3 should reduce a specific teardown bottleneck after an administrator has already chosen that design. It does not remove the operational trade-offs behind compressed memory.
KSM stops walking mappings it already knows are wrong
The KSM patch series has the more striking internal measurement. KSM deduplicates identical memory pages across processes: a useful technique for dense virtualization, similar containers, and certain large application fleets. When the kernel later needs to find mappings for a KSM page during reclaim, compaction, migration, or related work, rmap_walk_ksm() performs a reverse-map walk through the anonymous-memory virtual-area structures.
Xu Xin’s investigation found that 99.9 percent of iterations in one of those walks were being discarded immediately because the address did not fall inside the virtual memory area being inspected. The root cause was blunt: the lookup passed a page-offset range from zero to ULONG_MAX, essentially making the interval-tree traversal search every possible offset before rejecting almost every candidate.
An earlier version of the patch tried to derive a suitable offset from the memory address. Kernel developers Hugh Dickins, David Hildenbrand, and Lorenzo Stoakes identified a correctness hole: after mremap() moves a mapping, the current virtual address need not match the page offset recorded within the anonymous-VMA structures. A faster lookup that misses a moved KSM page would be worse than a slow one, because the page could become impossible to reclaim, migrate, or hot-remove until it was unmapped or KSM was disabled.
The revised series does the needed bookkeeping rather than gambling on the current address. It adds vm_pgoff to KSM’s reverse-map item and uses that saved offset to constrain the interval-tree lookup correctly. It also adds a tracepoint, a latency benchmark, and mremap() self-tests—the last part is significant because it tests the very edge case that invalidated the prior approach.
In the developer’s embedded-Linux measurement, the longest anon-VMA lock hold during a KSM reverse-map walk dropped from 228.65 ms to 0.396 ms. The loop went from 22,169 iterations—22,168 rejected for being outside the address range—to three iterations. Those are extraordinary figures, but they are a pathological-case result, not a generic KSM speed rating.
The test scenario described in the patch discussion involved roughly 20,000 VMAs sharing one anonymous-VMA structure. That can arise without an application calling fork(): memory-management patterns that repeatedly split mappings can build up the same shape. The supplied examples include JVM and Go runtime behavior using mprotect() for guard pages or garbage-collection barriers, and database processes using madvise(MADV_DONTNEED) over parts of large mappings.
KSM itself is not typically active by default. Kernel documentation says its run control defaults to zero and must ordinarily be set to one to start ksmd. That sharply limits the immediate audience for this optimization: it is relevant to systems that deliberately use KSM, not every desktop that upgrades to Linux 7.3. But for operators who enable deduplication to fit more guests or workers into RAM, the patch addresses a hidden cost of that density strategy—tail latency during memory-management operations.
The common theme is tail latency, not peak throughput
These series are related less by code than by failure mode. In both cases, Linux is doing memory cleanup or reverse mapping under conditions where latency has become more important than an average throughput number. A pool-wide allocator lock or an anon-VMA lock held for hundreds of milliseconds can block unrelated memory activity behind it.
That has concrete effects in modern deployments. A request-serving process may stop making progress while reclaim or page migration waits. A container can exceed a timeout even when CPU utilization looks low. A VM host can suffer delayed compaction or migration at exactly the point its memory-saving mechanisms are supposed to be helping it stay online.
Neither patch promises that every “out of memory” event becomes smooth. zRAM and Zswap still consume CPU to compress and decompress; KSM still has scanning overhead and can affect memory-access behavior; physical RAM shortages remain physical RAM shortages. What Linux 7.3 is doing is removing two avoidable serial waits from paths that magnify those shortages into user-visible stalls.
Administrators planning to evaluate Linux 7.3 should treat these as reasons to revisit existing pressure tests rather than reasons to change production configuration immediately. Test concurrent unmapping and reclaim on hosts that use zRAM or Zswap, and test migration, compaction, and reclamation on systems where KSM is actually enabled. The decisive metrics are likely to be long-tail request latency, reclaim delays, and container behavior—not a synthetic single-threaded memory score.
Linux 7.3’s memory-management pull is large, but these two changes stand out because they reduce work the kernel should never have serialized or repeated. The compressed-swap patch makes the freeing path scale better on supported 64-bit systems; the KSM patch makes a previously broad lookup precise while retaining correctness after mremap(). For workloads that match those patterns, the next kernel could make memory pressure feel less like a sudden stop.