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