Date: Tue, 13 Jul 1999 11:13:49 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: "Brian F. Feldman" <green@FreeBSD.ORG>, Noriyuki Soda <soda@sra.co.jp>, bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907131813.LAA79534@apollo.backplane.com> References: <199907131753.KAA22111@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907131813.LAA79534>