On Thu, 15 Jul 1999, Daniel C. Sobral wrote:

> John Nemeth wrote:
> > 
> >      The machine in question has run out of swap, due to unforseeable
> > excessive memory demands.  This was accompanied by processes
> > complaining about not being able to allocate memory and then cleaning
> > up after themselves.  I did not see random processes being killed
> > because of it.  That is the way things should be.  From this, I can
> > assume that the OS doesn't overcommit.  In case, you're wondering, the
> > OS in question is:
> > 
> > SunOS 5.5 Generic_103093-25 sun4u sparc
> 
> Uh... like any modern unix, Solaris overcommits.

Where do you guys get this misinformation?  

plus:~: uname -a
SunOS plus 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-1
plus:~: swap -s
total: 307240k bytes allocated + 19464k reserved = 326704k used, 151072k
available

Note the `19464k reserved'; that space has been reserved but not yet
allocated.


Now please stop cross-posting to tech-userlevel@netbsd.org.  This
discussion does not belong there since it's not userlevel and has degraded
to the point where it is bordering on the non-technical.  


So FreeBSD has come to the consensus that overcommit is good, at least for
them.  Fine.  That's no reason to try to force everyone else to accept
that view.  Frankly I would not consider an OS that does not gracefully
handle approaching system limits unstable and unfit for general use.  

Overcommit allows you to save a few $$ on disk space by living
dangerously.  High availablility operating systems cannot do that.  They
cannot go down.  On a $300K server spending an extra $2K on additional
swap disks is lost in the noise.  

Other arguments have been that you can make an overcommitting OS behave
similarly to a non-overcommitting OS by playing around with the limits.
That's not an acceptable solution.  The amount of work needed to get an OS
tuned to a particular job should be reduced, not increased.  In a number
of cases it may not be possible to tune the number of users X the number
of processes X the stack+data+BSS each process is allowed to use to a
number that lets anything even run on that machine.  In short, the OS
should be self-tuning.

Finally, there's the argument that once a machine has completely run out
of swap it's wedged and the sysadmin can't even log in to clean up the
mess.  Well that can readily be fixed the same way that running out of
processes can be fixed: reserve the last 10-20MB for root so the sysadmin
can log in and kill off appropriate processes. 


While there have have been other valid arguments for both sides, at the
moment this has become a rather useless argument due to the lack of
willingness to accept other views or opinions.  So until you people are
willing to entertain the though that you may not be the sole owners of the
gospel truth, please go away and stop bothering me.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me