From owner-freebsd-hackers Tue Jul 13 7:30:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id B582C151E3; Tue, 13 Jul 1999 07:30:52 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id XAA06904; Tue, 13 Jul 1999 23:28:22 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id XAA03944; Tue, 13 Jul 1999 23:28:20 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id XAA09584; Tue, 13 Jul 1999 23:28:21 +0900 (JST) Date: Tue, 13 Jul 1999 23:28:21 +0900 (JST) Message-Id: <199907131428.XAA09584@srapc342.sra.co.jp> From: Noriyuki Soda 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, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: References: <199907130912.SAA07964@srapc342.sra.co.jp> 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" said: >> > you also have to consider a program wishing to make sparse use >> > of its address space, without overcommit it becomes impossible. >> >> 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. MAP_NORESERVE is nothing related to page wiring (i.e. mlock()ing). From Solaris 2.6 man page: : The MAP_NORESERVE option specifies that no swap space be : reserved for a mapping. Without this flag, the creation of : a writable MAP_PRIVATE mapping reserves swap space equal to : the size of the mapping; when the mapping is written into, : the reserved space is employed to hold private copies of the : data. A write into a MAP_NORESERVE mapping produces results : which depend on the current availability of swap space in : the system. If space is available, the write succeeds and a : private copy of the written page is created; if space is not : available, the write fails and a SIGBUS or SIGSEGV signal is : delivered to the writing process. MAP_NORESERVE mappings are : inherited across fork(); at the time of the fork(), swap : space is reserved in the child for all private pages that : currently exist in the parent; thereafter the child's map- : ping behaves as described above. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message