From owner-freebsd-hackers  Tue Jul 13 15:45:44 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id E8CFF15088
	for <freebsd-hackers@FreeBSD.ORG>; Tue, 13 Jul 1999 15:45:35 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id PAA81515;
	Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
	(envelope-from dillon)
Date: Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199907132244.PAA81515@apollo.backplane.com>
To: Jason Thorpe <thorpej@nas.nasa.gov>
Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org
Subject: Re: Replacement for grep(1) (part 2) 
References:  <199907132230.PAA24729@lestat.nas.nasa.gov>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:On Tue, 13 Jul 1999 15:12:14 -0700 (PDT) 
: Matthew Dillon <dillon@apollo.backplane.com> 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).

    True enough, though that is something we could fix under FreeBSD.  Also
    irrelevant... anything that causes a page fault and allocates a page
    is effectively what we are talking about.

:...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 <thorpej@nas.nasa.gov>

    So far nobody has been able to justify any good reasons for adding it
    to the system.  I'm sorry, but just throwing out worst-case theories
    is not a good justification, nor is throwing embedded systems into the
    fray - because those already have to control memory fairly tightly
    and there are plenty of ways of doing that without having to do
    in-kernel reservation.  Throwing generic 'critical servers' into the
    fray also isn't appropriate, because any server that is that critical
    also implements its own memory alloction management.  It has to in
    order to guarentee performance and performance will degrade before
    one runs out of memory.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message