From owner-freebsd-hackers Tue Jul 13 10:55: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 58B3B14D57; Tue, 13 Jul 1999 10:54:55 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id KAA22111; Tue, 13 Jul 1999 10:53:49 -0700 (PDT) Message-Id: <199907131753.KAA22111@lestat.nas.nasa.gov> To: "Brian F. Feldman" Cc: Noriyuki Soda , 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) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 10:53:48 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 10:11:14 -0400 (EDT) "Brian F. Feldman" 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message