linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: linux-mm@kvack.org
Subject: Re: [QUESTION] Resizing shared mapping without clashing with others
Date: Mon, 2 Dec 2024 16:40:30 +0100	[thread overview]
Message-ID: <795a454b-a432-4200-8524-003e5ad53d03@redhat.com> (raw)
In-Reply-To: <avg5j6aepvei5z7disrb6myodg5wzppipfjahwtkx6rqjtrpri@q2kebwreu7ct>

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



  reply	other threads:[~2024-12-02 15:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-30 16:24 Dmitry Dolgov
2024-12-01 11:55 ` Matthew Wilcox
2024-12-01 18:44   ` Dmitry Dolgov
2024-12-01 20:57     ` Matthew Wilcox
2024-12-02 14:54       ` Dmitry Dolgov
2024-12-02 11:07 ` David Hildenbrand
2024-12-02 15:04   ` Dmitry Dolgov
2024-12-02 15:40     ` David Hildenbrand [this message]
2024-12-02 16:14       ` Dmitry Dolgov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=795a454b-a432-4200-8524-003e5ad53d03@redhat.com \
    --to=david@redhat.com \
    --cc=9erthalion6@gmail.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox