On Tue, 13 Jul 1999 10:11:14 -0400 (EDT)
"Brian F. Feldman" <gr...@freebsd.org> wrote:
> > SVR4 has MAP_NORESERVE option for mmap(2) for this.
> > So, default behaivour don't have to be overcommitment.
>
> Isn't that just like mmap()ing then mlock()ing the range? That would
> keep it in core.
No, it's not the same thing. On a system which does backing store
accounting, the mmap() will fail if you don't specify MAP_NORESRVE
and there isn't enough backing store.
Also, MAP_NORESERVE can affect things which happen in the future, i.e.
it "sticks" to the mapping. Consider:
addr = mmap file size MAP_PRIVATE PROT_READ <- no swap resources
required
mprotect addr size PROT_READ|PROT_WRITE <- swap resources now
required
The mprotect() could fail in a system that doesn't overcommit, unless
MAP_NORESERVE is specified in the mmap() call.
-- Jason R. Thorpe <thor...@nas.nasa.gov>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
