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

Pedro Falcato
2025-06-20T18:59:26Z

On Tue, Jun 17, 2025 at 11:57:11AM +0100, Lorenzo Stoakes wrote:
> On Tue, Jun 17, 2025 at 10:45:53AM +0200, David Hildenbrand wrote:
> > mremap() is already an expensive operation ... so I think we need a pretty
> > convincing case to make this configurable by the user at all for each
> > individual mremap() invocation.
>
> My measurements suggest, unless you hit a very unfortunate case of -huge
> faulted in range all mapped PTE- that the work involved is not all that
> much more substantial in terms of order of magnitude than a normal mremap()
> operation.
>

Could you share your measurements and/or post them on the cover letter for the
next version?

If indeed it makes no practical difference, maybe we could try to enable it by
default and see what happens...

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.

--
Pedro