From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Hongru Zhang <zhanghongru06@gmail.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,
liam@infradead.org, linux-kernel@vger.kernel.org,
baohua@kernel.org, mhocko@suse.com, rppt@kernel.org,
shakeel.butt@linux.dev, surenb@google.com, vbabka@kernel.org,
willy@infradead.org, zhanghongru@xiaomi.com
Subject: Re: [RFC PATCH v4 0/3] mm: retry page faults under per-VMA lock when possible
Date: Tue, 4 Aug 2026 12:47:36 +0100 [thread overview]
Message-ID: <anHQjuAbK-a-QGhJ@lucifer> (raw)
In-Reply-To: <20260804095135.45897-1-zhanghongru@xiaomi.com>
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
prev parent reply other threads:[~2026-08-04 11:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 9:51 [RFC PATCH v4 0/3] mm: retry page faults under per-VMA lock when possible Hongru Zhang
2026-08-04 11:47 ` Lorenzo Stoakes (ARM) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anHQjuAbK-a-QGhJ@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=zhanghongru06@gmail.com \
--cc=zhanghongru@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox