On Tue, 13 Jul 1999 10:11:14 -0400 (EDT) 
 "Brian F. Feldman" <green@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 <thorpej@nas.nasa.gov>