Date: Tue, 13 Jul 1999 10:53:48 -0700 From: Jason Thorpe <thorpej@nas.nasa.gov> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: Noriyuki Soda <soda@sra.co.jp>, bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907131753.KAA22111@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
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>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907131753.KAA22111>