Two Very Exciting Memory Management Optimizations Going Into Linux 7.3

Locking Contention in zs_free()

The first optimization reduces locking contention in zs_free(), which is used by Zswap and zRAM for releasing compressed RAM pages. Locking contention within zs_free() can be significant in the unmapping path when systems are under memory pressure either on Google Android devices or on servers with Zswap-heavy workloads. Given the increase in Zswap/zRAM usage with today's memory prices especially for large servers, this locking contention optimization can be very helpful.

In benchmarking the performance impact of this reduced locking contention within zsmalloc, both a 20-core Intel system and small Raspberry Pi 4B benefited nicely when measuring the time for each process independently mapping 256MB, writing data, madvise'ing page-out to swap out via zRAM, and then concurrent unmapping. Wenchao Hao of Xiaomi found that the Raspberry Pi sped up by as much as 1.83x in this operation while the Intel system was up to 1.4x.

Performance Optimizations for rmap_walk_ksm()

Separately, but also part of the MM pull request, are performance optimizations for rmap_walk_ksm(). The rmap_walk_ksm memory management function is for carrying out a reverse map walk for pages managed via Kernel Samepage Merging (KSM). ZTE engineers discovered a "severe" performance problem with KSM reverse-mapping where applications can freeze for hundreds of milliseconds under memory pressure. The problem was most pronounced when a lot of unrelated VMAs share a single anon_vma.

The problem is so severe that lock hold times dropped from more than 500ms to less than 2ms! In the worst case scenario going from 705ms down to a 1.44ms average or 1.67ms max. Xu Xin of ZTE elaborated on the performance impact and some real-world examples in the prior patch series:

"Two key highlights: 1. Lock hold time drops from >500ms to - In our benchmark (20,000 VMAs sharing an anon_vma), worst-case anon_vma lock hold time during KSM rmap walk went from 705ms down to 1.67ms (max) and 1.44ms (avg). 2. Real user impact - The anon_vma lock is also acquired by page faults, reclaim, migration, compaction, mlock, exit_mmap, and cgroup accounting. - A long hold due to inefficient rmap walks stalls application threads, causing latency spikes, reduced throughput, or even container timeouts. - The problem occurs even without fork() – VMA splitting (e.g., via mprotect or madvise over time) can create tens of thousands of VMAs all attached to the same anon_vma. Real-world examples: - JVM / Go runtime: These use mmap for heap regions and later call mprotect(PROT_NONE) for garbage collection barriers or guard pages, splitting the original VMA into thousands of small pieces over time. - Database engines (MySQL, PostgreSQL): Large shared memory buffers or anonymous mappings are managed with madvise(MADV_DONTNEED) to release specific pages, which also splits VMAs.

• Why the benchmark numbers are realistic: We observed ~20,000 VMAs sharing one anon_vma on a production system running a Java application with KSM enabled. The lock hold time before the patch was measured at 228 ms (max) during rmap walks triggered by memory compaction and page migration. The benchmark reproduces that VMA count and lock‑hold behavior in a controlled environment. For systems that do not have thousands of VMAs per anon_vma, the patch adds negligible overhead (a single pgoff comparison). For systems that do suffer from this issue, the improvement is dramatic: 1) Worst‑case anon_vma lock hold time drops from hundreds of milliseconds to under 2 ms.2)This directly reduces blocking of parallel operations that need the same lock – page faults, reclaim, migration, compaction, mlock, and exit_mmap. End‑users will see lower tail latency (fewer application stalls), higher throughput under memory pressure, and no more spurious lockup warnings or container timeouts caused by excessive lock hold times.

In short: workloads that do not hit this pathological pattern are unaffected; those that do will see a 100x to 500x reduction in lock hold times, which translates directly into a more responsive system.