Date: Thu, 15 Apr 1999 11:08:52 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mikhail Teterin <mi@misha.cisco.com> Cc: current@FreeBSD.ORG Subject: Re: swap on Irix (overcommiting, etc.) Message-ID: <199904151808.LAA47676@apollo.backplane.com> References: <199904151744.NAA98408@misha.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Irix, each swap area has the following parameter (from swap(1M)):
:
: vswap The size the system believes the area can hold. This is
: always greater than or equal to pswap and maxswap.
:
:This way, an administrator can control the amount of overcommited
:memory (making it 0 if neccessary). It may be sufficient to have
:this as a centralized parameter, rather then a per swap area.
:
:They also have priorities of the swap areas (only swap here when
:areas with higher priorities are full), and an ability to stop
:paging onto a particular area. Mmmm...
:
: -mi
I think they finally got rid of vswap in later IRIX's after they
fixed the core swapping code to 'overcommit'. The reality behind
the virtual swap concept w/ IRIX is based on issues with the original
SysV VM system. IRIX wanted to assign swap to everything, whether it
needed it or not. For example, each instance of a MAP_PRIVATE map would
get swap backing store assigned to it whether it needed it or not.
In fact, I think even MAP_SHARED maps reserved swap under older IRIX
systems. Again, fixed in newer systems.
Requiring swap pre-allocation to avoid overcommits may sound like a nice
idea, but it doesn't work in practice. Before IRIX's vswap came along,
system administrators had to assign 10 times the amount of swap as a
system actually needed to operate. On a modern system with 256MB of ram,
that would come to over 2 Gigabytes of swap with the worst-case actual
utilization sitting at around 200 MBytes of swap.
It's A total waste of disk space.
Not only that, but any system that actually had to use that much swap
would pile drive right into the ground performance-wise... you would
lose anyway, even if you could guarentee that no swap overcommit could
occur.
FreeBSD does it right - it only allocates swap when it needs to swap
something out of main memory. The total available VM is essentially
the amount of main memory plus the amount of swap ( non-inclusive of
mmap()'d files which do not take any swap at all ).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904151808.LAA47676>