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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Tue, Jun 24, 2025 at 11:38:59AM +0200, David Hildenbrand wrote:
> On 20.06.25 21:28, Lorenzo Stoakes wrote:
> > I have some ideas... :)

Note that I've been working hard on a respin, figuring out ways to
basically make it so we can't fail to set up folios (afaict) so we get
predictable undo.

Of course we make life very very hard for ourselves in mm :)

>
> As a first step, we could have some global way to enable/disable the
> optimization system-wide. We could then learn if there is really any
> workload that notices the change, while still having a way to revert to the
> old behavior on affected systems easily.

Yeah I was wondering if we could do something like this... I mean we could
hide it in /sys/kernel/mm worst case.

>
> Just a thought, I still hope we can avoid all that. Again, mremap() is not
> really known for being a very efficient operation.

Agreed, and I don't think we should microbenchmark it so much. I think as long
as it's roughly the same order of magnitude time taken then it should be fine?

>
> >
> > >
> > > 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. 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.

>
>
> --
> Cheers,
>
> David / dhildenb
>

Anyway, let me polish up the respin and we can see how that goes :)
stress-ng is helping...