Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux