| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <cccf352a-1a68-430d-83fa-a14bb5e37464@oppo.com> Date: Sun, 4 Jan 2026 17:16:24 +0800 From: Oven Liyang <liyangouwen1@...o.com> To: Barry Song <21cnbao@...il.com>, akpm@...ux-foundation.org, linux-mm@...ck.org Cc: Barry Song <v-songbaohua@...o.com>, Russell King <linux@...linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>, Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>, Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>, Alexander Gordeev <agordeev@...ux.ibm.com>, Gerald Schaefer <gerald.schaefer@...ux.ibm.com>, Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>, David Hildenbrand <david@...nel.org>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, "Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, Matthew Wilcox <willy@...radead.org>, Pedro Falcato <pfalcato@...e.de>, Jarkko Sakkinen <jarkko@...nel.org>, Oscar Salvador <osalvador@...e.de>, Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>, Mark Rutland <mark.rutland@....com>, Ada Couprie Diaz <ada.coupriediaz@....com>, Robin Murphy <robin.murphy@....com>, Kristina Martšenko <kristina.martsenko@....com>, Kevin Brodsky <kevin.brodsky@....com>, Yeoreum Yun <yeoreum.yun@....com>, Wentao Guan <guanwentao@...ontech.com>, Thorsten Blum <thorsten.blum@...ux.dev>, Steven Rostedt <rostedt@...dmis.org>, Yunhui Cui <cuiyunhui@...edance.com>, Nam Cao <namcao@...utronix.de>, Chris Li <chrisl@...nel.org>, Kairui Song <kasong@...cent.com>, Kemeng Shi <shikemeng@...weicloud.com>, Nhat Pham <nphamcs@...il.com>, Baoquan He <bhe@...hat.com>, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, loongarch@...ts.linux.dev, linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [RFC PATCH 0/2] mm: continue using per-VMA lock when retrying page faults after I/O On 11/27/2025 9:14 AM, Barry Song wrote: > > From: Barry Song <v-songbaohua@...o.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@...linux.org.uk> > Cc: Catalin Marinas <catalin.marinas@....com> > Cc: Will Deacon <will@...nel.org> > Cc: Huacai Chen <chenhuacai@...nel.org> > Cc: WANG Xuerui <kernel@...0n.name> > Cc: Madhavan Srinivasan <maddy@...ux.ibm.com> > Cc: Michael Ellerman <mpe@...erman.id.au> > Cc: Nicholas Piggin <npiggin@...il.com> > Cc: Christophe Leroy <christophe.leroy@...roup.eu> > Cc: Paul Walmsley <pjw@...nel.org> > Cc: Palmer Dabbelt <palmer@...belt.com> > Cc: Albert Ou <aou@...s.berkeley.edu> > Cc: Alexandre Ghiti <alex@...ti.fr> > Cc: Alexander Gordeev <agordeev@...ux.ibm.com> > Cc: Gerald Schaefer <gerald.schaefer@...ux.ibm.com> > Cc: Heiko Carstens <hca@...ux.ibm.com> > Cc: Vasily Gorbik <gor@...ux.ibm.com> > Cc: Christian Borntraeger <borntraeger@...ux.ibm.com> > Cc: Sven Schnelle <svens@...ux.ibm.com> > Cc: Dave Hansen <dave.hansen@...ux.intel.com> > Cc: Andy Lutomirski <luto@...nel.org> > Cc: Peter Zijlstra <peterz@...radead.org> > Cc: Thomas Gleixner <tglx@...utronix.de> > Cc: Ingo Molnar <mingo@...hat.com> > Cc: Borislav Petkov <bp@...en8.de> > Cc: x86@...nel.org > Cc: H. Peter Anvin <hpa@...or.com> > Cc: David Hildenbrand <david@...nel.org> > Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com> > Cc: Liam R. Howlett <Liam.Howlett@...cle.com> > Cc: Vlastimil Babka <vbabka@...e.cz> > Cc: Mike Rapoport <rppt@...nel.org> > Cc: Suren Baghdasaryan <surenb@...gle.com> > Cc: Michal Hocko <mhocko@...e.com> > Cc: Matthew Wilcox <willy@...radead.org> > Cc: Pedro Falcato <pfalcato@...e.de> > Cc: Jarkko Sakkinen <jarkko@...nel.org> > Cc: Oscar Salvador <osalvador@...e.de> > Cc: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com> > Cc: Oven Liyang <liyangouwen1@...o.com> > Cc: Mark Rutland <mark.rutland@....com> > Cc: Ada Couprie Diaz <ada.coupriediaz@....com> > Cc: Robin Murphy <robin.murphy@....com> > Cc: Kristina Martšenko <kristina.martsenko@....com> > Cc: Kevin Brodsky <kevin.brodsky@....com> > Cc: Yeoreum Yun <yeoreum.yun@....com> > Cc: Wentao Guan <guanwentao@...ontech.com> > Cc: Thorsten Blum <thorsten.blum@...ux.dev> > Cc: Steven Rostedt <rostedt@...dmis.org> > Cc: Yunhui Cui <cuiyunhui@...edance.com> > Cc: Nam Cao <namcao@...utronix.de> > Cc: Chris Li <chrisl@...nel.org> > Cc: Kairui Song <kasong@...cent.com> > Cc: Kemeng Shi <shikemeng@...weicloud.com> > Cc: Nhat Pham <nphamcs@...il.com> > Cc: Baoquan He <bhe@...hat.com> > Cc: linux-arm-kernel@...ts.infradead.org > Cc: linux-kernel@...r.kernel.org > Cc: loongarch@...ts.linux.dev > Cc: linuxppc-dev@...ts.ozlabs.org > Cc: linux-riscv@...ts.infradead.org > Cc: linux-s390@...r.kernel.org > Cc: linux-mm@...ck.org > Cc: linux-fsdevel@...r.kernel.org > > -- > 2.39.3 (Apple Git-146) >
Powered by blists - more mailing lists