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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02.12.24 16:04, Dmitry Dolgov wrote:
On Mon, Dec 02, 2024 at 12:07:01PM GMT, David Hildenbrand wrote:

Likely it's best to look into reserving a large VMA space using
mmap(MAP_PRIVATE|MA_ANON, PROT_NONE); it's reserved but inaccessible, so it
cannot get reallocated for different purposes. Then converting pieces of
that into actually usable shared anonymous memory (e.g., MAP_FIXED).

Yes, we've considered this option, preparing an initial "reserving"
mapping, then take pieces out of it for usage. As I've mentioned to
Matthew, there seems to be arguments against this approach. In a few
words:

Note that this approach is extremely common ;)


* The impact on OOM decisions is not clear (at least to me).

There are none. mmap(MAP_PRIVATE|MAP_ANON, PROT_NONE) will neither allocate memory/page tables nor commit memory.

* In certain cases this will be counted against a reservation limits,
   although we don't use the memory yet (e.g. with hugetlb insige a
   cgroup with hugetlb.2MB.rsvd.limit_in_bytes set).


With mmap(MAP_PRIVATE|MAP_ANON, PROT_NONE)? Unlikely. In any case, you might be able to tame reservations using MAP_NORESERVE.


--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux