: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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
