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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message