Discussion:
Flag MAP_NORESERVE for mmap() implemented in NetBSD 3.0?
(too old to reply)
Sourath Roy
2006-11-13 12:42:23 UTC
Permalink
Hi,
I want to know if flag MAP_NORESERVE be supported/implemented for mmap() in
NetBSD 3.0. I can find the define in mman.h, so ofcourse it would allow the
code to compile. But is it really implemented in NetBSD 3.0? I can't find
this flag being documented in man pages for mmap() for NetBSD and so was
curious.

Thanks for any help!

-- Sourath
Christian Biere
2006-11-14 14:48:24 UTC
Permalink
Post by Sourath Roy
I want to know if flag MAP_NORESERVE be supported/implemented for mmap() in
NetBSD 3.0. I can find the define in mman.h, so ofcourse it would allow the
code to compile. But is it really implemented in NetBSD 3.0? I can't find
this flag being documented in man pages for mmap() for NetBSD and so was
curious.
MAP_NORESERVE occurs in header files only and nowhere else in the sources. So
it's not used anywhere.
--
Christian

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Sourath Roy
2006-11-14 18:25:57 UTC
Permalink
I thought so. I believe there's no equivalent either...

Now any clues whether NetBSD does overcommit during memory allocations like
Linux does?

-- Sourath
Post by Christian Biere
Post by Sourath Roy
I want to know if flag MAP_NORESERVE be supported/implemented for mmap()
in
Post by Sourath Roy
NetBSD 3.0. I can find the define in mman.h, so ofcourse it would allow
the
Post by Sourath Roy
code to compile. But is it really implemented in NetBSD 3.0? I can't
find
Post by Sourath Roy
this flag being documented in man pages for mmap() for NetBSD and so was
curious.
MAP_NORESERVE occurs in header files only and nowhere else in the sources. So
it's not used anywhere.
--
Christian
Christian Biere
2006-11-15 10:01:31 UTC
Permalink
Post by Sourath Roy
Now any clues whether NetBSD does overcommit during memory allocations like
Linux does?
I don't think it does. At least, I can mmap() 1 GiB with MAP_ANON|MAP_PRIVATE
without having that much RAM and swap being disabled. The program crashes
during memset() then. With swap enabled it doesn't crash. So there's no
guarantee that the mapped memory is actually accesible or available.
--
Christian

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
SODA Noriyuki
2006-11-15 10:46:34 UTC
Permalink
Post by Christian Biere
Post by Sourath Roy
On Wed, 15 Nov 2006 11:01:31 +0100,
Now any clues whether NetBSD does overcommit during memory allocations like
Linux does?
I don't think it does.
Well, the following behavior is called "overcommitting".
i.e. NetBSD (and all Mach derived VMs) does overcommit for now.
Post by Christian Biere
At least, I can mmap() 1 GiB with MAP_ANON|MAP_PRIVATE
without having that much RAM and swap being disabled. The program crashes
during memset() then. With swap enabled it doesn't crash. So there's no
guarantee that the mapped memory is actually accesible or available.
See also kern/12451
--
soda

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Christian Biere
2006-11-15 11:42:18 UTC
Permalink
Post by SODA Noriyuki
Post by Christian Biere
Post by Sourath Roy
On Wed, 15 Nov 2006 11:01:31 +0100,
Now any clues whether NetBSD does overcommit during memory allocations like
Linux does?
I don't think it does.
Well, the following behavior is called "overcommitting".
i.e. NetBSD (and all Mach derived VMs) does overcommit for now.
Ok, then I had its meaning backwards. You can map a read-writeable file with
MAP_SHARED, so that the file is used as backing store. If the memory guarantee
is more important than the performance hit, this might be an option.
--
Christian

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Jason Thorpe
2006-11-15 17:31:07 UTC
Permalink
Post by Sourath Roy
I thought so. I believe there's no equivalent either...
Now any clues whether NetBSD does overcommit during memory
allocations like Linux does?
Yes, NetBSD's VM system implements an overcommit policy.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Sourath Roy
2006-11-16 18:46:19 UTC
Permalink
If NetBSD implements memory overcommit policy, then in cases where there is
no real memory would the behavior be same as Linux? i.e., OOM coming in and
killing processes randomly?
Is there a way to stop this overcommit policy in NetBSD?

-- Sourath
Post by Jason Thorpe
Post by Sourath Roy
I thought so. I believe there's no equivalent either...
Now any clues whether NetBSD does overcommit during memory
allocations like Linux does?
Yes, NetBSD's VM system implements an overcommit policy.
-- thorpej
Christian Biere
2006-11-20 10:08:48 UTC
Permalink
Post by Sourath Roy
If NetBSD implements memory overcommit policy, then in cases where there is
no real memory would the behavior be same as Linux? i.e., OOM coming in and
killing processes randomly?
As nobody answered this, yes, as far as I can tell that's the case. If you
run out of swap or disable it, you likely see processes killed with a
"UVM: [...] killed: out of swap" logged to the console.
Post by Sourath Roy
Is there a way to stop this overcommit policy in NetBSD?
Not as far as I know. However, mlock() does not require privileges on NetBSD,
so every user can lock physical memory up to a configured resource limit. So if
you wanted to make sure a certain process is never killed due to running out of
memory, you could modify it to use mmap() + mlock() possibly even by overriding
malloc() et al. with LD_PRELOAD. Otherwise, you have to ensure, you have enough
swap for the worst case and likely offenders should have tight memory resource
limits.
--
Christian

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...