Linux 7.3 slashes memory-management lock contention by up to 500×
Two optimizations merged into the Linux 7.3 merge window cut memory-management lock contention: the worst-case anon_vma lock hold time drops from 705 ms to 1.67 ms, and the zsmalloc path speeds up by as much as 1.83× on modest hardware. Teams running JVMs, databases or KSM under memory pressure get a direct latency win just from upgrading.
August 19, 2026. Andrew Morton sends the memory management (MM) updates for the Linux 7.3 merge window: 1,250 patches, against 920 the previous cycle. September 6, 2026. Linux 7.3-rc2 ships, and the series moves toward a stable release. Two optimizations buried in that patch flow concretely change life for servers under memory pressure: one drops the worst-case lock hold time from 705 ms to 1.67 ms, the other accelerates the zsmalloc path by up to 1.83×. For an SRE, this is the kind of win that needs no configuration change — just a kernel.
A lock held for 705 milliseconds, brought down to 1.67
The first optimization targets rmap_walk_ksm(), the function that walks the reverse mapping for pages managed by KSM (Kernel Samepage Merging). The problem, found by ZTE engineers, was “severe”: when many unrelated VMAs share a single anon_vma, the reverse walk holds the anon_vma lock for hundreds of milliseconds under memory pressure.
The exact number is striking. In a benchmark reproducing 20,000 VMAs sharing one anon_vma, the worst-case lock hold time falls from 705 ms to 1.67 ms maximum, and 1.44 ms on average — a 100× to 500× reduction.
Why does this matter beyond the micro-benchmark? Because the anon_vma lock is not reserved for KSM. It is also taken by page faults, reclaim, migration, compaction, mlock, exit_mmap and cgroup accounting. A long hold caused by an inefficient reverse walk stalls application threads: latency spikes, lower throughput, and sometimes container timeouts.
Xu Xin, the ZTE engineer behind the fix, gives concrete production examples. JVM and Go runtimes use mmap for heap regions then call mprotect(PROT_NONE) for collection barriers or guard pages, splitting the original VMA into thousands of fragments over time. Database engines like MySQL and PostgreSQL do the same with madvise(MADV_DONTNEED). The result: tens of thousands of VMAs attached to one anon_vma on machines doing nothing exotic.
The zsmalloc path, accelerated even on a Raspberry Pi
The second optimization reduces lock contention in zs_free(), the release function of the zsmalloc allocator used by zswap and zRAM to free compressed pages. This contention shows up most in the unmapping path under memory pressure — typically on Google Android devices or servers with heavy zswap workloads.
The benchmark speaks for itself. Wenchao Hao of Xiaomi measured the “map 256 MB, write, madvise to page out to zRAM, then concurrently unmap” operation: a 20-core Intel system gained up to 1.4×, and a modest Raspberry Pi 4B up to 1.83×. That the sharpest gain lands on the smallest hardware is no accident — that is where lock contention weighs proportionally the most.
For servers, the stakes are tied to memory prices. With the recent surge in DDR5 costs, zswap and zRAM become first-order economic levers: compressing part of RAM is cheaper than buying more sticks. Lower contention in zsmalloc makes that trade-off less painful in latency, and therefore easier to defend.
A patch flood the AI helped summarize
The context deserves a parenthesis. Andrew Morton explicitly noted that the 1,250 “added-to-MM” emails this cycle represented a 36% jump over the 920 of the previous cycle, and that he had turned to Google’s Gemini AI to write his patch summaries. That is a signal of scale: the volume of kernel contribution now exceeds what one human maintainer can summarize by hand.
The news is good for Linux 7.3’s memory management, but it is also good for the readability of the process. When a maintainer delegates synthesis to a model, the quality of the summary depends on the quality of the prompt — and the fact that Morton pulled two major optimizations out of a 1,250-patch flood shows the tool served human judgment, not replaced it.
What to remember for your servers
The decisive point is that these gains require no configuration. Neither KSM nor zswap needs a new setting: the optimizations act inside the kernel, on paths already taken by the workloads that suffer them. The upgrade is enough.
Just check whether your workloads are affected. A system with KSM enabled is inspected in one command:
cat /sys/kernel/mm/ksm/run # 1 = KSM enabled, 0 = disabled
cat /sys/kernel/mm/ksm/pages_shared # pages actually mergedIf KSM is active on a machine hosting JVMs, Go runtimes or databases, you are squarely in the target population for the rmap_walk_ksm fix. If you use zswap or zRAM to carry memory-pressured workloads, you benefit from the zs_free fix.
Verdict
Linux 7.3 is not just another kernel cycle: its memory-management optimizations attack a class of latency that ops teams endure without being able to diagnose — lock contention that freezes threads for hundreds of milliseconds. The numbers from ZTE and Xiaomi turn an invisible problem into a measurable win.
If you run JVMs, Go runtimes or databases under memory pressure with KSM enabled, plan the move to Linux 7.3 at its stable release and measure tail latency before and after: the reduction in lock hold time shows up directly on the high percentiles.
If you use zswap or zRAM to contain memory costs, the zs_free fix makes the compression/latency trade-off more favorable — one more reason to stay current rather than freeze a kernel that “still works”.
If your workloads enable neither KSM nor zswap, you will likely see nothing: these fixes are surgical, and that is exactly their quality. Update for security and the other fixes, without expecting a latency miracle.