Date: Tue, 13 Jul 1999 14:25:33 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907132125.OAA72872@bubba.whistle.com> In-Reply-To: <199907132109.OAA80706@apollo.backplane.com> from Matthew Dillon at "Jul 13, 99 02:09:56 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907132125.OAA72872>