:Both Dillon and Sobral mistakenly claimed that "Solaris overcommits",
:this fact seems to be somewhat suggestive.
:
:And also, the followings are allocated memory and reserved memory 
:in my environment. (This table also includes Eduardo's example)
:
:	SunOS	allocated reserved    total total/allocated
:	-----	--------- -------- -------- ------------
:	4.1.4       4268k    1248k    5516k 1.2924  
:	4.1.2       7732k    1492k    9224k 1.193   
:	4.1.4       8848k    3080k   11928k 1.3481  
:	4.1.4      13532k    6772k   20304k 1.5004  
:	5.5.1      15312k    5092k   20404k 1.3325  
:	4.1.3      16112k    6512k   22624k 1.4042  
:	4.1.2      26356k    1620k   27976k 1.0615  
:	4.1.4      26560k    3756k   30316k 1.1414  
:	5.5        26076k   11348k   37424k 1.4352  
:	4.1.4      32984k    5556k   38540k 1.1684  
:	5.6        32448k    7072k   39520k 1.2179  
:	4.1.4      38056k    3692k   41748k 1.097   
:	4.1.4      49064k    7672k   56736k 1.1564  
:	4.1.4      67012k    7800k   74812k 1.1164  
:	4.1.4      99348k   16956k  116304k 1.1707  
:	4.1.4     118288k   11780k  130068k 1.0996  
:	5.6       231968k   18880k  250848k 1.0814  
:	5.7       307240k   19464k  326704k 1.0634  
:
:	(sorted by total amount of used swap)
:
:In those examples, non-overcommiting system requires 1.06x ... 1.50x
:...
:soda

    Umm... how are you getting the reserved numbers?  Are you
    sure that isn't simply cached swap blocks?  I.E. when something
    gets swapped out and then is swapped back in and dirtied,
    Solaris may be holding the swap block assignment rather
    then letting it go.  FreeBSD-stable does the same thing.
    FreeBSD-current does not -- it lets it go in order to be
    able to reallocate it later as part of a contiguous swath
    for performance reasons.

    These 'extra' swap blocks are effectively reserved but not
    actually allocated.  They can be reassigned.  The numbers
    above are very similar to what you would see in a
    redirtying-cache swap block situation on a FreeBSD-stable
    system.

    If I add up all the unshared writeable segments on my
    home box - that is, all segments for which one would 
    potentially have to reserve swap space - I get a total
    of around 382MB.  The machine is currently eating around
    100MB of ram and 5MB of swap, or around a 3.5:1 ratio
    in this case.  A non-overcommit model would have to 
    reserve swap space for 382MB - 100MB = 282MB verses the
    5MB of swap the machine actually allocates.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>