Performance loss with word count benchmark

[Liam R. Howlett]

* Julia Lawall <julia.lawall at inria.fr> [230929 14:25]:
> 
> 
> On Fri, 29 Sep 2023, Matthew Wilcox wrote:
> 
> > On Thu, Sep 28, 2023 at 06:32:01PM +0200, Julia Lawall wrote:
> > > https://github.com/kozyraki/phoenix
> > >
> > > The test is in phoenix-2.0
> > >
> > > It can be run as
> > >
> > > tests/word_count/word_count word_count/word_count_datafiles/word_100MB.txt
> > >
> > > I think you have to download the word_100MB.txt file separately.
> >
> > Thanks, Julia.  Bringing in some other people that care about maple tree
> > performance.
> >
> > A quick glance at strace doesn't show much in the way of calls to mmap.
> > Using strace -f to make sure I capture all the threads shows a lot of
> > anon mmap calls, but mostly of 41 and 81 pages in length (164kB, 324kB).
> > That might be a libc malloc artefact?
> >
> > Ooh, just found one that's 161 pages.  But there are a lot of calls to
> > mprotect; that's going to create new VMAs, right?
> 
> Zillions of calls to mprotect.  They also come all at the same time, over
> and over.  I can make some graphs to show what is going on.

Thanks for the offer.  If it isn't too much trouble I'd appreciate it.
The more data the better for these issues.  If these are grouped
together and in the same area we may not even have per-VMA locking
success on page faults.

I suspect mprotect is causing the VMA to be split into 2 or 3 every
call, and (at least) attempting to merge.

Regards,
Liam