linux-kernel - Re: [PATCH] mm: Always sanity check anon

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJuCfpEqJV9Lv+36xNK+vnpsR5DhQ0kCK3CW7tLFWbbbSCH8yg@mail.gmail.com>
Date: Fri, 26 Apr 2024 08:32:06 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Peter Xu <peterx@...hat.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	Andrew Morton <akpm@...ux-foundation.org>, Lokesh Gidra <lokeshgidra@...gle.com>, 
	Alistair Popple <apopple@...dia.com>
Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks

On Fri, Apr 26, 2024 at 8:28 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Fri, Apr 26, 2024 at 08:07:45AM -0700, Suren Baghdasaryan wrote:
> > On Fri, Apr 26, 2024 at 7:00 AM Matthew Wilcox <willy@...radeadorg> wrote:
> > > Intel's 0day got back to me with data and it's ridiculously good.
> > > Headline figure: over 3x throughput improvement with vm-scalability
> > > https://lore.kernel.org/all/202404261055.c5e24608-oliver.sang@intel.com/
> > >
> > > I can't see why it's that good.  It shouldn't be that good.  I'm
> > > seeing big numbers here:
> > >
> > >       4366 ą  2%    +565.6%      29061        perf-stat.overall.cycles-between-cache-misses
> > >
> > > and the code being deleted is only checking vma->vm_ops and
> > > vma->anon_vma.  Surely that cache line is referenced so frequently
> > > during pagefault that deleting a reference here will make no difference
> > > at all?
> >
> > That indeed looks overly good. Sorry, I didn't have a chance to run
> > the benchmarks on my side yet because of the ongoing Android bootcamp
> > this week.
>
> No problem.  Darn work getting in the way of having fun ;-)
>
> > > I still don't understand why we have to take the mmap_sem less often.
> > > Is there perhaps a VMA for which we have a NULL vm_ops, but don't set
> > > an anon_vma on a page fault?
> >
> > I think the only path in either do_anonymous_page() or
> > do_huge_pmd_anonymous_page() that skips calling anon_vma_prepare() is
> > the "Use the zero-page for reads" here:
> > https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L4265. I
> > didn't look into this particular benchmark yet but will try it out
> > once I have some time to benchmark your change.
>
> Yes, Liam and I had just brainstormed that as being a plausible
> explanation too.  I don't know how frequent it is to use anon memory
> read-only.  Presumably it must happen often enough that we've bothered
> to implement the zero-page optimisation.  But probably not nearly as
> often as this benchmark makes it happen ;-)

I also wonder if some of this improvement can be attributed to the
last patch in your series
(https://lore.kernel.org/all/20240426144506.1290619-5-willy@infradead.org/).
I assume it was included in the 0day testing?