Two Linux 7.3 memory changes reduce contention in different paths: reverse mapping for KSM and freeing compressed objects through zsmalloc. Their measurements describe specific operations, not a universal application speedup.

KSM: narrow the reverse lookup
The memory-management pull request includes Xu Xin’s KSM optimization. KSM shares identical anonymous pages; reverse mapping finds the mappings associated with a shared page. Many split virtual-memory areas can belong to the same anon_vma, making an overly broad search expensive.
The v11 patch description uses a suitable page index to restrict that search. In its benchmark with 20,000 VMAs sharing an anon_vma, maximum lock-hold time falls from 705 ms to 1.67 ms, with a patched average of 1.44 ms. The production Java observation cited separately had a 228 ms maximum before the change. Those are two different observations.
Other operations needing the same lock can wait behind the walk. This explains a latency mechanism; it does not mean an entire machine always freezes for 705 ms. Nor does it identify the cause of an unexplained guest timeout without measurements.
zsmalloc: reduce two sources of contention
Wenchao Hao’s v6 series targets concurrent freeing of compressed pages. A suitable object encoding identifies the size class without the pool read lock; page freeing also moves outside the class lock.
The implementation retains the pool-lock path when the encoding cannot hold the class index. This includes 32-bit systems and some 64-bit configurations. “Every 64-bit build removes that lock” would therefore be too broad.
The developer’s zram test maps and fills 256 MB per process, pages it out using lzo-rle and then unmaps concurrently. On the Raspberry Pi 4B, the four-process case changes from 202.9 to 110.6 ms, about 1.83×. The single-process case is 59 to 56 ms. Concurrency changes the result; the larger multiplier cannot stand in for every workload.
Keep measurement and inference separate
The cover plots the Pi results on the same time scale. An original calculation gives about 45.5% less elapsed time for the four-process case, versus roughly 5.1% for the single-process case. These calculations interpret published developer measurements; they are not new hardware tests.
Before evaluating a kernel change, record whether KSM or compressed swap is actually active. Keep compressor, memory pressure and concurrency constant, and measure the implicated operation alongside application latency. A system that never exercises KSM cannot gain from its reverse-map optimization. A compressed-swap user may exercise zsmalloc without exercising KSM at all.
Attribute synthetic KSM and zram measurements, distinguish 228ms production observation and encoding-limited 64-bit lock removal.