Re: [DISCUSSION] anon_vma root lock contention and per anon_vma lock

[David Hildenbrand <david@redhat.com>]

On 11.09.25 09:17, Barry Song wrote:
> Hi All,
> 
> I’m aware that Lokesh started a discussion on the concurrency issue
> between usefaultfd_move and memory reclamation [1]. However, my
> concern is different, so I’m starting a separate discussion.
> 
> In the process tree, many processes may share anon_vma->root, even if
> they don’t share the anon_vma itself. This causes serious lock contention
> between memory reclamation (which calls folio_referenced and try_to_unmap)
> and other processes calling fork(), exit(), mprotect(), etc.
> 
> On Android, this issue becomes more severe since many processes are
> descendants of zygote.
> 
> Memory reclamation path:
>    folio_lock_anon_vma_read
> 
> mprotect path:
>    mprotect
>      split_vma
>        anon_vma_clone
> 
> fork / copy_process path:
>    copy_process
>      dup_mmap
>        anon_vma_fork
> 
> exit path:
>    exit_mmap
>      free_pgtables
>        unlink_anon_vmas
> 
> To be honest, memory reclamation—especially folio_referenced()—is a
> problem. It is called very frequently and can block other important
> user threads waiting for the anon_vma root lock, causing UI lag.
> 
> I have a rough idea: since the vast majority of anon folios are actually
> exclusive (I observed almost 98% of Android anon folios fall into this
> category), they don’t need to iterate the anon_vma tree. They belong to
> a single process, and even for rmap, it is per-process.
> 
> I propose introducing a per-anon_vma lock. For exclusive folios whose
> anon_vma is not shared, we could use this per-anon_vma lock.
> folio_referenced declares that it will begin reading, and Lokesh’s
> folio_lock may also help maintain folios as exclusive, so I am
> somewhat in favor of his RFC. Any thread writing to such an anon_vma
> would take the per-vma write lock, and possibly also the anon_vma
> root write lock. If folio_referenced fails to declare the per-vma lock,
> it can fall back to the global anon_vma->root read mutex, similar to
> mmap_lock.

To summarize, are you proposing a similar locking scheme like we have 
for mm vs. vma here for anon-vma root vs. anon-vma?

-- 
Cheers

David / dhildenb