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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
