[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZivILlyRv7rNMldQ@casper.infradead.org>
Date: Fri, 26 Apr 2024 16:28:46 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Suren Baghdasaryan <surenb@...gle.com>
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 08:07:45AM -0700, Suren Baghdasaryan wrote:
> On Fri, Apr 26, 2024 at 7:00 AM Matthew Wilcox <willy@...radead.org> 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 ;-)
Powered by blists - more mailing lists