:>     have to allocate anyway if we were to actually disallow overcommits!  But
:>     with overcommits allowed, your box will never come close to using that
:>     much swap.
:
:This may be a decent answer for the workstation world, but it's not so
:good for more restricted systems.  Further, your claim that
:disallowing overcommit gains you absolutely nothing is simply false.
:
:It gains you two things (which are at least immediately obvious to me):
:
:* Certain knowledge that (if the system is implemented correctly) the
:  system will never have to kill a process (or take similar corrective
:  action) due to overcommit, and that attempts to allocate more backing
:  store resources than are present will fail.

    By the time the system reaches the point where it would have to do
    this in the case where you reserve sufficient swap to handle a 
    situation where overcommits would not be allowed, the system will
    *ALREADY BE DEAD*.

    Please read my other posting carefully.  Certain knowledge doesn't 
    help you if the system becomes unuseable first.

    Swap overcommit is a non-problem.

:* protection against bogosity.
:
:  I may run a system in which all of the processes are effectively
:  unlimited (i.e. have huge resource limits), but I know within a
:  tolerance what the actual expected usage of the system is.

    Set a resource limit that is, say, 1/2 your swap space.  Problem 
    solved.   

    Of course there are plenty of potential situations where this will
    not work... what if two processes run away?  What if 10 processes
    run away?  What if they ALL run away?  But the reality is that you
    can think up these potentialities until you are blue in the face and
    you will never solve your problem.  Even advocating a system which
    does not allow overcommit will not solve your problem... the result
    of that will be a system which starts refusing to do things long before
    it would otherwise.  This is unacceptable.

    You have to think of the problem in terms of what will realistically 
    occur in a system.  Trying to solve any other problem will not help
    make the system more reliable.  You will wind up running in circles trying
    to solve problems that never occur instead of solving the problems that
    do occur.

:cgd
:-- 
:Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>