From owner-freebsd-hackers Tue Jul 13 14:27:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D440214DD2 for ; Tue, 13 Jul 1999 14:27:25 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id OAA72872; Tue, 13 Jul 1999 14:25:33 -0700 (PDT) From: Archie Cobbs Message-Id: <199907132125.OAA72872@bubba.whistle.com> Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132109.OAA80706@apollo.backplane.com> from Matthew Dillon at "Jul 13, 99 02:09:56 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 13 Jul 1999 14:25:33 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > :How hard would it be to add a sysctl variable that controlled whether or not > :the system would overcommit memory? > > Archie, the question is barely worth answering. Nobody advocating this > stuff has even begun to think-out the ramifications. Adding such a knob > would be easy - except it might as well be a "crash me now" knob when > the system starts refusing programs reasonable requests for memory! > > I mean, jeeze, the reservation for the program stack alone would eat > up all your available swap space! What is a reasonable stack size? The > system defaults to 8MB. Do we rewrite every program to specify its own > stack size? How do we account for architectural differences? > > * stack > * MAP_PRIVATE mmaps > * fork (used to fork, not the 'easy' fork/exec case) > > It adds up pretty quickly. My home server runs smoothly with 128MB of > ram and 512MB of swap (4MB of swap in use), but the kernel reports over > 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. What you say is generally true; however, the problem is that *you* are making implicit assumptions about what applications *I* might have in mind. I just think that's a presumptous thing to do unless you can read minds.. For example: - I might be creating a very limited embedded system with just a few small processes that are all written to *handle* out of memory situations. - I could be creating a "Java OS" that is going to have a single process, ie, the Java VM, that can handle ENOMEM (which translates into an OutOfMemoryException, which can be caught) but otherwise *must not die*. In types of situations like this (someone can probably think of more/better examples) overcommit may very well be undesireable. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message