Re: [RFC PATCH 0/2] mm: continue using per-VMA lock when retrying page faults after I/O

[Oven Liyang <liyangouwen1@oppo.com>]

On 11/27/2025 9:14 AM, Barry Song wrote:
> 
> From: Barry Song <v-songbaohua@oppo.com>
> 
> Oven observed most mmap_lock contention and priority inversion
> come from page fault retries after waiting for I/O completion.
> Oven subsequently raised the following idea:
> 
> There is no need to always fall back to mmap_lock if the per-VMA
> lock was released only to wait for pagecache or swapcache to
> become ready.
> 
> In this case, the retry path can continue using the per-VMA lock.
> This is a big win: it greatly reduces mmap_lock acquisitions.
Here are some test data for the patches:

== Test Case ==

Douyin (Chinese version of TikTok) warm start on smart phone with 8GB RAM


== mmap_lock Acquisitions And Wait Time ==

Metric                    Before (Avg)    After (Avg)    Change
------------------------------------------------------------------------
Read Lock Count           20,010          5,719          -71.42%
Read Total Wait (us)      10,695,877     408,436        -96.18%
Read Avg Wait (us)        534.00         71.00           -86.70%
Write Lock Count          838             909            +8.47%
Write Total Wait (us)     501,293        97,633          -80.52%
Write Avg Wait (us)       598.00         107.00          -82.11%


== Read Lock Waiting Time Distribution of mmap_lock ==

Range (us)                 Before (Avg)    After (Avg)    Change
------------------------------------------------------------------------
[0, 1)                     9,927           4,286          -56.82%
[1, 10)                    9,179           1,327          -85.54%
[10, 100)                  191             88             -53.93%
[100, 1000)                57              6              -89.47%
[1000, 10000)              328             9              -97.26%
[10000, 100000)            328             6              -98.17%
[100000, 1000000)          0               0              N/A
[1000000, +)               0               0              N/A


== Write Lock Waiting Time Distribution of mmap_lock ==

Range (us)                 Before (Avg)    After (Avg)    Change
------------------------------------------------------------------------
[0, 1)                     250             300            +20.00%
[1, 10)                    483             556            +15.11%
[10, 100)                  52              41             -21.15%
[100, 1000)                12              5              -58.33%
[1000, 10000)              22              4              -81.82%
[10000, 100000)            16              1              -93.75%
[100000, 1000000)          0               0              N/A
[1000000, +)               0               0              N/A


After the optimization, the number of read lock acquisitions is 
significantly reduced, and both lock waiting time and tail latency are 
dramatically improved.

Thanks,
Oven
> 
> Oven Liyang (1):
>    mm/filemap: Retry fault by VMA lock if the lock was released for I/O
> 
> Barry Song (1):
>    mm/swapin: Retry swapin by VMA lock if the lock was released for I/O
> 
>   arch/arm/mm/fault.c       |  5 +++++
>   arch/arm64/mm/fault.c     |  5 +++++
>   arch/loongarch/mm/fault.c |  4 ++++
>   arch/powerpc/mm/fault.c   |  5 ++++-
>   arch/riscv/mm/fault.c     |  4 ++++
>   arch/s390/mm/fault.c      |  4 ++++
>   arch/x86/mm/fault.c       |  4 ++++
>   include/linux/mm_types.h  |  9 +++++----
>   mm/filemap.c              |  5 ++++-
>   mm/memory.c               | 10 ++++++++--
>   10 files changed, 47 insertions(+), 8 deletions(-)
> 
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Paul Walmsley <pjw@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Alexandre Ghiti <alex@ghiti.fr>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
> Cc: Sven Schnelle <svens@linux.ibm.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Pedro Falcato <pfalcato@suse.de>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Cc: Oven Liyang <liyangouwen1@oppo.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Kristina Martšenko <kristina.martsenko@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Cc: Yeoreum Yun <yeoreum.yun@arm.com>
> Cc: Wentao Guan <guanwentao@uniontech.com>
> Cc: Thorsten Blum <thorsten.blum@linux.dev>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Yunhui Cui <cuiyunhui@bytedance.com>
> Cc: Nam Cao <namcao@linutronix.de>
> Cc: Chris Li <chrisl@kernel.org>
> Cc: Kairui Song <kasong@tencent.com>
> Cc: Kemeng Shi <shikemeng@huaweicloud.com>
> Cc: Nhat Pham <nphamcs@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: loongarch@lists.linux.dev
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-riscv@lists.infradead.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-fsdevel@vger.kernel.org
> 
> --
> 2.39.3 (Apple Git-146)
>