Re: [QUESTION] Resizing shared mapping without clashing with others

[Dmitry Dolgov <9erthalion6@gmail.com>]

> On Sun, Dec 01, 2024 at 08:57:07PM GMT, Matthew Wilcox wrote:
> > Right, mapping with the larger size than needed is one option we're
> > considering. But there are few arguments against that:
> >
> > * Folks are wary of unnecessary large shared mappings, since in the past
> >   there were issues with OOM killer making unfavorable to postgres
> >   decisions because of that. It might have changed over time, but to
> >   confirm that will require some investigation.
> >
> > * It can cause memory accounting problems. E.g. if we use hugetlb inside
> >   a cgroup with reservation limits set (something like
> >   hugetlb.2MB.rsvd.limit_in_bytes), then such mmap() will be counted
> >   against the limit, even though the memory wasn't allocated -- meaning
> >   that we claim some resource without using it.
>
> If it does turn out to be a problem, you can use a similar trick to how
> ld.so maps binaries:
>
> mmap(NULL, 2055640, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f221a758000
> mmap(0x7f221a780000, 1462272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7f221a780000
> mmap(0x7f221a8e5000, 352256, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18d000) = 0x7f221a8e5000
> mmap(0x7f221a93b000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e2000) = 0x7f221a93b000
> mmap(0x7f221a941000, 52696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f221a941000
>
> Although you wouldn't want to do consecutive mmaps, you'd want to use
> mremap() with MREMAP_FIXED -- not to change new_address, but to expand
> length over the initial reserving-space mapping.

Hm, I don't follow how would that help? From what I understand the
suggestion is to have an initial mapping to "reserve" the space, right?
But this initial mapping would also be a subject of reservation limits,
mentioned above. I was originally experimenting with that, "reserving"
some mapping space with PROT_NONE, then slicing off chunks of it for
real usage -- but in case of hugetlb and a cgroup it was accounting
against the reservation limits for huge pages.