: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 
                                        <dil...@backplane.com>




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to