Received-SPF: pass (google.com: domain of linux-kernel+bounces-141658-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 11 Apr 2024 23:02:32 +0100
From: Matthew Wilcox <willy@infradead.org>
To: Peter Xu <peterx@redhat.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Lokesh Gidra <lokeshgidra@google.com>,
	Alistair Popple <apopple@nvidia.com>
Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks
Message-ID: <Zhhd-A7w1A8JUadM@casper.infradead.org>
References: <20240410170621.2011171-1-peterx@redhat.com>
 <20240411171319.almhz23xulg4f7op@revolver>
 <ZhhSItiyLYBEdAX3@x1n>
 <ZhhV3PKgEX9d7_vA@casper.infradead.org>
 <ZhhaRXHKk7w_hKgi@x1n>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZhhaRXHKk7w_hKgi@x1n>

On Thu, Apr 11, 2024 at 05:46:45PM -0400, Peter Xu wrote:
> On Thu, Apr 11, 2024 at 10:27:56PM +0100, Matthew Wilcox wrote:
> > On Thu, Apr 11, 2024 at 05:12:02PM -0400, Peter Xu wrote:
> > > The question is whether that's intended to make it as complicated.  For
> > > example, why don't we check anon_vma for anonymous too later when prepare
> > > anon_vma, however we do it late for file memory.  AFAICT there's nothing
> > > special with file memory in this case.
> > 
> > Yes, it's absolutely intended.  If anything, anon memory is the special
> > case that checks up-front.
> > 
> > Congratulations on adding additional instructions to the common case.
> > I don't understand why you persist with your nonsense.  Please stop.
> 
> How many instructions it takes for a late RETRY for WRITEs to private file
> mappings, fallback to mmap_sem?

Doesn't matter.  That happens _once_ per VMA, and it's dwarfed by the
cost of allocating and initialising the COWed page.  You're adding
instructions to every single page fault.  I'm not happy that we had to
add extra instructions to the fault path for single-threaded programs,
but we at least had the justification that we were improving scalability
on large systems.  Your excuse is "it makes the code cleaner".  And
honestly, I don't think it even does that.

> Did you even finish reading the patch at all?

Yes, I read the whole thing.  It's garbage.