From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B35624886A; Thu, 27 Nov 2025 04:10:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764216621; cv=none; b=kUuSTKik6skAh57b9AtbGw1HqIgAVs5gcUN/vSe24LDbKJRe8NuwJbu9J2FQXGdjt3JAtg116Hf9/KYDobDd2VZaWmOKm13bOkY7BnX2272gecCKtFlXRlhNlJeDpWigRQrg2AI9Q7At4lC9nRidWxg1UrDgiw3Cv9cctVAF1ss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764216621; c=relaxed/simple; bh=ooxdkvf2rxgsy0xRVRRnZiTwICu8IYYojYmiU6bahEI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tGYdPz6iJontL0/WjVY+AB3G+dSmKbIyjEvkBcxxOwvU/tkcMPX3zWNVkpzuUY4mhlY3uMyrucdIHwxdoxMY5cFunBmon0IJbFbfZ5RIinD5Bg5jiAGWWJXo3WAcLIB8SSPiPmmT1zkmXFpMRPD1CnukFwqV8C9nHBd79HrZDSg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=AP3I5dIw; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="AP3I5dIw" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9UH5HZWU7w1Qz5ka8h7XjqhmojO13fL0L+YMlTFhSDA=; b=AP3I5dIw8MUlt7xSzk3qgcc3sN AHu26Cs0wtwdgwSRwY+BmvEPRpHfoPjKAv6EqeaGAtEZ8MvH02yG8ScNHL7P49Rb/gM+u6ij5a6XG jy4hg3/q6KDo+jTVMSPbxO9fXKm9iGjW+uF8fMcq7GPSByWP3cICDpktaeP3bee4XCg1AvMMv/Moj YSEuEpY6zqKoGrYyt7uU+flpdycrYQcResJLx8oQU2IoaQaPpPfiBo/O1co/fExGrf5J1lFda0oK/ nNuM2+NAvUP42wEG8HkfVsWnCKASM8uniovBmROKgYy8568Nvncst6z24djS+35maVgZIA3CoAYDO v2Mud80A==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOTJl-0000000BB6Z-3S6J; Thu, 27 Nov 2025 04:09:17 +0000 Date: Thu, 27 Nov 2025 04:09:17 +0000 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Pedro Falcato , Jarkko Sakkinen , Oscar Salvador , Kuninori Morimoto , Oven Liyang , Mark Rutland , Ada Couprie Diaz , Robin Murphy , Kristina =?utf-8?Q?Mart=C5=A1enko?= , Kevin Brodsky , Yeoreum Yun , Wentao Guan , Thorsten Blum , Steven Rostedt , Yunhui Cui , Nam Cao , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 0/2] mm: continue using per-VMA lock when retrying page faults after I/O Message-ID: References: <20251127011438.6918-1-21cnbao@gmail.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251127011438.6918-1-21cnbao@gmail.com> On Thu, Nov 27, 2025 at 09:14:36AM +0800, Barry Song wrote: > 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. Something I've been wondering about is removing all the "drop the MM locks while we wait for I/O" gunk. It's a nice amount of code removed: include/linux/pagemap.h | 8 +--- mm/filemap.c | 98 ++++++++++++------------------------------------- mm/internal.h | 21 ----------- mm/memory.c | 13 +------ mm/shmem.c | 6 --- 5 files changed, 27 insertions(+), 119 deletions(-) and I'm not sure we still need to do it with per-VMA locks. What I have here doesn't boot and I ran out of time to debug it.