On 8/22/23 11:03, Warner Losh wrote:
> Hmm, bug with linux-user as well, because here we should re-establish the reserved_va
> reservation.
>
>
> ... of the shared memory region we just detached? Right?
Correct.
On a related note, on FreeBSD is there any practical difference between
PROT_NONE, MAP_ANON
and
PROT_NONE, MAP_GUARD
for large memory regions?
They do different things. MAP_ANON maps the memory without a backing
device. This means it allocates the VA space right away, but lazily allocates
the backing pages as the pages are dirtied.
MAP_GUARD creates the VA mapping, but never maps any pages to those
pages (well, until it's remapped). Any read/write/exec access to MAP_GUARD
pages results in a SIGSEGV.
I ask since FreeBSD doesn't have MAP_NORESERVE, which Linux uses to avoid allocation of
gigabytes
Yea. It sounds like MAP_NORESERVE is what FreeBSD's default behavior is: We don't
allocate backing store in the swap areas until there's memory pressure. You can safely
allocate GB of space with MAP_ANON and get similar behavior to the MAP_NORESERVE.
MAP_GUARD could be used if you wanted to reserve the VA space, but didn't want to assign
anything to the VA space until later.
As a practical matter, they both consume about the same resources until the MAP_ANON
region starts to get populated with data...
With PROT_NONE, I think they would have the same effect. If it is to be a backing store for
something like malloc, then MAP_ANON would be best. If you are replacing it with a lot of
things, like a mix of files, devices and/or anon memory, then MAP_GUARD and replace it
with MAP_FIXED later. Most likely you'll want MAP_GUARD to reserve the area, and then
MAP_FIXED to use it for mmap'd memory, shared memory, executable pages, etc.
Does that tell you what you need to know?
Warner
r~