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

Lorenzo Stoakes
2025-06-17T10:21:06Z

Replying to parent but quickly reply here also... out of order, like pulp
fiction...

On Tue, Jun 17, 2025 at 09:34:16AM +0100, Pedro Falcato wrote:
> On Mon, Jun 16, 2025 at 10:41:20PM +0200, David Hildenbrand wrote:
> > On 16.06.25 22:24, David Hildenbrand wrote:
> > > Hi Lorenzo,
> > >
> > > as discussed offline, there is a lot going on an this is rather ... a
> > > lot of code+complexity for something that is more a corner cases. :)
> > >
> > > Corner-case as in: only select user space will benefit from this, which
> > > is really a shame.
> > >
> > > After your presentation at LSF/MM, I thought about this further, and I
> > > was wondering whether:
> > >
> > > (a) We cannot make this semi-automatic, avoiding flags.
> > >
> > > (b) We cannot simplify further by limiting it to the common+easy cases
> > > first.
> > >
> > > I think you already to some degree did b) as part of this non-RFC, which
> > > is great.
> > >
> > >
> > > So before digging into the details, let's discuss the high level problem
> > > briefly.
> > >
> > > I think there are three parts to it:
> > >
> > > (1) Detecting whether it is safe to adjust the folio->index (small
> > > folios)
> > >
> > > (2) Performance implications of doing so
> > >
> > > (3) Detecting whether it is safe to adjust the folio->index (large PTE-
> > > mapped folios)
> > >
> > >
> > > Regarding (1), if we simply track whether a folio was ever used for
> > > COW-sharing, it would be very easy: and not only for present folios, but
> > > for any anon folios that are referenced by swap/migration entries.
> > > Skimming over patch #1, I think you apply a similar logic, which is good.
> > >
> > > Regarding (2), it would apply when we mremap() anon VMAs and they happen
> > > to reside next to other anon VMAs. Which workloads are we concerned
> > > about harming by implementing this optimization? I recall that the most
> > > common use case for mremap() is actually for file mappings, but I might
>
> realloc() for mmapped allocations commonly calls mremap(), FYI (at least for
> glibc, and musl; can't bother to look at the rest).
>
> > > be wrong. In any case, we could just have a different way to enable this
> > > optimization than for each and every mremap() invocation in a process.
>
> /me thinks of prctl
>
> :P

God please :P

>
>
> FWIW, with regards to the whole feature: While I do understand it's purpose (
> relocating anon might be too much for most workloads, but great for some), I'm
> uncomfortable with the amount of internals we're exposing here. Who's to say
> this is how mm rmap looks in 20 years? And we're stuck maintaining the userspace
> ABI until then.

I'm not sure what internals exactly we're exposing... if we have a future (I am
working on it...) where anon rmap works better then these flags become no-ops
right?

Unless you just mean the name?

I am open to changing the name but I think I already changed it based on what I
thought David might say :P

>
> Personally, I would prefer if we just had a flag 'MREMAP_HARDER' that would
> vaguely be documented as "mremap but harder, even if have to do a little more
> work". Then we could move things around without promising RELOCATE_ANON makes
> conceptual sense, and userspace wouldn't have to think through the implications
> of such a flag by reading Lorenzo's great book.

Well thanks for book plug ;)

I think that's far too vague though. I don't think users would have any idea
what that's supposed to help. And then how does the MREMAP_MUST_RELOCATE_ANON
flag work here?

Naming is hard, basically.

>
> --
> Pedro
>