Re: [PATCH v11 0/3] KSM: performance optimizations for rmap_walk_ksm

[Andrew Morton]

On Fri, 3 Jul 2026 16:22:53 +0800 (CST) <xu.xin16@xxxxxxxxxx> wrote:

> This series fixes a severe KSM reverse-mapping performance problem
> that can freeze applications for hundreds of milliseconds under
> memory pressure especially when a lot of unrelated VMAs sharing a
> single anon_vma.
> 
> Two key highlights:
> 
> 1. Lock hold time drops from >500ms to <2ms
>    - 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:

Again, thanks for persisting with this.  Great improvement and I'd love
to see us get this finished off.

Please have a look through the AI review:

	https://sashiko.dev/#/patchset/20260703162253688u8Str9eFLR8TGCmo7nIOF@xxxxxxxxxx

That 32-bit thing looks legit, kinda fatal but easy to address.