Date: Tue, 13 Jul 1999 14:09:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907132109.OAA80706@apollo.backplane.com> References: <199907132026.NAA72481@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:How hard would it be to add a sysctl variable that controlled whether or not :the system would overcommit memory? : :-Archie : :___________________________________________________________________________ :Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com 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. So, as I said before: in order for overcommit prevention to work you need to have an insane amount of swap, even though the system could not possibly use it all. Not only is it a complete waste of space, but if you were to reserve that much swap for a *normal* system that allowed overcommits, rather then the 2xMEM that we currently recommend, hell would freeze over before you managed to actually use it all. If you tried to turn on an overcommit knob without multiplying your swap space to the insane purportions necessary, the system will start refusing allocation requests long before the system actually reaches a point of performance degredation, turning your nice fast pentium-II into the equivalent of an 386 with 8MB of ram. Protecting against overcommit may sound like a cool idea, but the reality is that you can't do it without seriously compromising the performance potential of a system and you can't do it without wasting a lot of space. And, besides, it doesn't work anyway. As I've said on several occassions a system will die from disk overload long before it would come close to using available swap given a reasonable configuration. Just because the WWW server processes are stilll there doesn't mean squat if they can't answer queries! -Matt 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?199907132109.OAA80706>