From owner-freebsd-hackers Mon Jul 12 21: 8:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 6ECF0150CF for ; Mon, 12 Jul 1999 21:08:26 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id AAA11980; Tue, 13 Jul 1999 00:15:59 -0400 (EDT) Date: Mon, 12 Jul 1999 23:15:57 -0500 (EST) From: Alfred Perlstein To: "Daniel C. Sobral" Cc: Jon Ribbens , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <378A8D4C.AFDCCD66@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Daniel C. Sobral wrote: > Jon Ribbens wrote: > > > > "Daniel C. Sobral" wrote: > > > That's *not* abomination. How about pre-allocating over 100 Mb for X > > > Free, for instance? > > > > What about it? If an application does not need 100MB, it should not > > malloc it. If it does need it, it should malloc it and know that it > > is available if the malloc succeeds. > > Well, learn something about real programs first, and then come back. > > > > Basically, if you don't have enough memory, you just don't have enough > > > memory. > > > > Yes, and the application should be told this via the standard > > documented interface for doing so, i.e. returning NULL from > > malloc(). > > This results in the applications working with less memory than would > actually be possible through overcommit. > > > > What FreeBSD does *reduces* the need for memory. If FreeBSD *did > > > not* do it, then you'd need much more memory. > > > > Why? Are there really such a lot of applications allocating vastly > > more memory than they actually use? > > Right. > You're not really being fair by giving such simple answers, not that it hasn't been discussed TO DEATH already so i understand your indifference. :) I didn't understand the reasoning of over commit until I was pointed out this scenario: (let's use netscape because it is huge) You're browsing with netscape and It hits about 32megs in size, you click on a multimedia object and netscape execs a helper app. at the moment of the fork you have a major overcommit, considering private mappings and allocated memory that is suddenly doubled when under a second later you will exec a program that is only a meg or so. you also have to consider a program wishing to make sparse use of its address space, without overcommit it becomes impossible. if you want to impose limits, use /etc/login.conf, nuff said. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message