From owner-freebsd-hackers Tue Jul 13 16:12: 5 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 939F3152FD for ; Tue, 13 Jul 1999 16:11:45 -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 QAA25089; Tue, 13 Jul 1999 16:10:46 -0700 (PDT) Message-Id: <199907132310.QAA25089@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 16:10:46 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 15:44:40 -0700 (PDT) Matthew Dillon wrote: > 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. Well, all I can say is: I'm sure glad you don't have any influence over the code base I run. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message