This topic has been rehashed a thousand times.

    What it comes down to is that if you want to disallow overcommit, you
    have to multiply the amount of swap space in the system relative to
    current levels in order to get the same performance limits as you had
    before.  If you don't, your system will begin to fail much earlier
    then it would have otherwise.  The reason for this is simple:  the
    system generally doesn't even come close to using an amount of swap
    matching its VM reservation.

    Rather then reserving the 2xMEMORY worth of swap that we recommend now,
    you would have to reserve 8x or 16xMEMORY worth of swap if overcommits
    were not allowed.

    It doesn't make much sense to do that.  It's a terrible waste of 
    resources.  A machine with 128MB of ram would have to reserve 2G
    worth of swap space instead of 256MB to be able to reach the performance
    limits of the machine, yet under nearly all conditions no more then 
    200MB of that space would actually be used by the system.  The
    performance curve starts to drop out once swap utilization reaches 1.5xMEM
    and is really in the dogpile when swap utilization reaches 2xMEM.  There
    is no benefit whatsoever to allocating more swap then the system can
    have reasonable performance with except as an emergency reserve.

    Thus it makes little sense to try to disallow overcommit.  It gains you
    absolutely nothing, and forces you to waste huge amounts of disk space.

    To anyone who is paranoid about it:  Fine, then just allocate an insane
    amount of swap and forget about it.  It would be no more then you would
    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.

    SysV was totally and utterly broken in regards to swap allocation.  The
    only major operating system that used it as a base was IRIX and SGI
    found out very quickly that pre-reserving swap is a stupid idea - and
    so they implemented 'virtual swap' to get around it in 5.3, and moved the
    whole thing to an overcommit model in 6.4.  Doh!  Even solaris doesn't
    overcommit - you think it actually reserves data blocks for its file-backed
    swap?  Bzzt!  It uses an overcommit model too.

						-Matt