Subject: RE: Replacement for grep(1) (part 2)
To: 'Brian F. Feldman' <green@FreeBSD.org>
From: Ladavac Marino <email@example.com>
Date: 07/13/1999 16:26:05
> -----Original Message-----
> From: Brian F. Feldman [SMTP:green@FreeBSD.org]
> Sent: Tuesday, July 13, 1999 4:11 PM
> To: Noriyuki Soda
> Cc: firstname.lastname@example.org; email@example.com; freebsd-hackers@FreeBSD.org;
> firstname.lastname@example.org; email@example.com; firstname.lastname@example.org
> Subject: Re: Replacement for grep(1) (part 2)
> On Tue, 13 Jul 1999, Noriyuki Soda wrote:
> > > You're browsing with netscape and It hits about 32megs in size,
> > > you click on a multimedia object and netscape execs a helper app.
> > If the system has real vfork(2) like NetBSD, this is not problem.
> > > 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.
[ML] AFAIK, no.
NORESERVE specifies that the backing storage will not be reserved
until actual allocation on pageout. If at that time no backing storage is
unreserved, the process will probably die (my memory hazes somewhat at this
point). FreeBSD behaves as if every page has been NORESERVE mapped.
This topic has been trashed to death a few months ago. There is no
win-win situation in presence of processes which allocate a lot of memory
without actually using it (read: your typical FORTRAN library).
The conclusion was that in order to be absolutely safe, one has to
have at least as much swap as the intended working set, regardless of the
memory overcommit. Memory overcommit may let you get away without such swap
most of the time, but sometimes the luck may run out.
> > --
> > soda
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
> green@FreeBSD.org _ __ ___ | _ ) __| \
> FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
> http://www.FreeBSD.org/ _ |___/___/___/
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message