From owner-freebsd-hackers Tue Jul 13 15:31:26 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 3A71715345 for ; Tue, 13 Jul 1999 15:31:21 -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 PAA24729; Tue, 13 Jul 1999 15:30:45 -0700 (PDT) Message-Id: <199907132230.PAA24729@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 15:30:44 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 15:12:14 -0700 (PDT) Matthew Dillon wrote: > The text size of a program is irrelevant, because swap is never > allocated for it. The data and BSS are only relevant when they > are modified. Bzzt. BSS is relevant when accessed (at least in NetBSD). > There is a lot of hidden 'potential' VM that you haven't considered. > For example, if the resource limit for a process's stack is 8MB, then > the process can potentially allocate 8MB of stack even though it may > actually only allocate 32K of stack. When a process forks, the child ...um, so, make the code that deals with faulting in the stack a bit smarter. > :* not all the world's a general purpose computing environment, > > Which is meaningless handwaving. Again, you are welcome to point out > your own real-life situations. Well, I just gave you a few examples of "not a general computing environment" in different mail. > I had to deal with a reservation model on our old SGI's running 5.3 > for almost a year. I know what I'm talking about and I can point to > real-life cases that demonstrate it. Certainly there are many different > situations... you are welcome to bring up other real-life situations > as examples. ...and as I recall, those SGIs at BEST were general-purpose computing environments. Chris already said that disallowing overcommit wasn't necessarily appropriate in every situation. So make it a knob. Big deal. Everyone has what they want. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message