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

[David Hildenbrand <david@redhat.com>]

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