Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON

[David Hildenbrand]

> > > > Or: separate but maybe awful idea, but if the problem is the number of VMAs
> > > > maybe we could try harder based on the map count? i.e if
> > > > map_count > (max_map_count / 2), try to relocate anon.
> > >
> > > Interesting, though that'd make some things randomly merge and other stuff not,
> > > and you really have to consistently do this stuff to make things mergeable.
> >
> > Yes, I'd prefer if we can make it more predictable.
> >
> > (Of course, the VMA region size could also be used as an input to a policy.
> > e.g., small move -> much fragmentation -> merge, large move -> less
> > fragmentation -> don't care. Knowing about the use cases that use mremap()
> > of anon memory and how they might be affected could be very valuable. Maybe
> > it's mostly moving a handful of pages where we most care about this
> > optimization?).
>
> I think fundamentally there are two problems:
>
> 1. Unexpected VMA fragmentation leading to later mremap() failure.
> 2. Unnecessary VMA proliferation.
>
> So we could fix 1 with a 'allow multiple VMAs to be moved if no resize'
> patch.

Yes. Which might end up easier (well, okay, different level of 
complexity, at least not messing with folio->)

And of course the relocate anon stuff is about 2.
> In theory we could combine it, but things could become complicated as then
> it's mulitple VMA/anon_vma merges.

Yes.

--
Cheers,

David / dhildenb