Re: [RFC PATCH v4 0/3] mm: retry page faults under per-VMA lock when possible

Re: [RFC PATCH v4 0/3] mm: retry page faults under per-VMA lock when possible

[Lorenzo Stoakes (ARM)]

Your series was sent in a broken way somehow, all the patches should be
in-reply-to the cover, not separate (unless my client screwed it up somehow :)

On Tue, Aug 04, 2026 at 05:51:35PM +0800, Hongru Zhang wrote:
> This v4 reworks the v3 approach in response to review feedback: it keeps

You shouldn't put stuff about the review process in the cover. it should
summarise what you're trying to do in the series.

In mm we append the cover letter to the first commit in the series once
merged so try to avoid superfluous stuff.

> VM_FAULT_RETRY unchanged and introduces VM_FAULT_MAY_USE_VMA_LOCK as an
> advisory opt-in bit. Fault handlers can return
> VM_FAULT_RETRY | VM_FAULT_MAY_USE_VMA_LOCK when a retry may continue
> under the per-VMA lock, and architecture fault handlers perform at most
> one bounded VMA-lock retry by setting FAULT_FLAG_TRIED before retrying.
> This preserves the existing fallback behavior for retry paths that do
> not opt in.
>
> Patch 1 adds the new advisory bit and the bounded retry plumbing.
> Patch 2 lets filemap faults opt in to VMA-lock retry.
> Patch 3 lets swap faults opt in to VMA-lock retry.
>
> We tested this on a 20-core Intel i7-12700 desktop with a 2GB swapfile.
> For the filemap workload, we adapted the v2 stress model to a 20-core
> desktop by reducing the thread count and adjusting the memcg limits. The
> benchmark uses concurrent file-backed page faults under memcg pressure
> with parallel munmap to amplify mmap_lock read-write contention.
> Throughput improved by 31.3% to 69.5%, while mmap_lock contention
> dropped by about 97.8% to 97.9%.

That's good information thanks!

>
> For the swap workload, we use a non-zero anonymous mapping under memcg
> pressure with optional mmap writer threads. Throughput improved by 6.3%
> to 47.1%, with the largest gain under four mmap writers.
>
> The detailed benchmark tables are in the individual patch changelogs.
> Build testing was done with C=1 on x86, arm, arm64, loongarch, powerpc,
> riscv and s390, with no new warnings in the touched files.
>
> Changes since v3:
> - Keep VM_FAULT_RETRY unchanged and add VM_FAULT_MAY_USE_VMA_LOCK as an advisory bit
> - Bound VMA-lock retries with FAULT_FLAG_TRIED
> - Opt in filemap_fault() and do_swap_page() to VM_FAULT_MAY_USE_VMA_LOCK
> - Rebased on mm-unstable

you should list all the changes for _all_ of the revisions. you should also
prefix with RFC given these are all RFC's presumably. You should also credit
people where revisions are a result of review.

>
> Link to v3:
> https://lore.kernel.org/all/20260626075019.1833065-1-zhanghongru@xiaomi.com/
>
> Link to v2:
> https://lore.kernel.org/all/20260430040427.4672-1-baohua@kernel.org/
>
> Link to v1:
> https://lore.kernel.org/all/20251127011438.6918-1-21cnbao@gmail.com/
>
> Hongru Zhang (3):
>   mm: allow page faults to request VMA-lock retry
>   mm/filemap: allow filemap faults to retry under the VMA lock
>   mm/swap: allow swap faults to retry under the VMA lock
>
>  arch/arm/mm/fault.c       |  6 ++++--
>  arch/arm64/mm/fault.c     |  7 +++++--
>  arch/loongarch/mm/fault.c |  6 ++++--
>  arch/powerpc/mm/fault.c   |  6 ++++--
>  arch/riscv/mm/fault.c     |  6 ++++--
>  arch/s390/mm/fault.c      |  5 +++--
>  arch/x86/mm/fault.c       |  6 ++++--
>  include/linux/mm.h        | 28 ++++++++++++++++++++++++++++
>  include/linux/mm_types.h  |  4 ++++
>  mm/filemap.c              |  2 +-
>  mm/memory.c               |  4 +++-
>  11 files changed, 64 insertions(+), 16 deletions(-)
>
>
> base-commit: 486855239e38a91d3eae26618ccb7845c1764625
> --
> 2.43.0
>

--
Cheers, Lorenzo