Sorry, thought I'd alluded to that in my original reply.
Long version: Read the Memory Management Whitepaper (
http://docs.hp.com/en/1218/mem_mgt.html).Short and sweet version: UNIX virtual memory systems typically work by having each physical page in use have a potential page of swap ready in case it needs to be paged out. [This is swap reservation, as opposed to swap *consumption* where the data is actually written out to the swap device/FS and swapinfo reports bytes USED]. There are a few algorithms on how and when to do this, Linux in particular waits until physical memory is allocated (on a page fault, usually) to reserve the corresponding swap -- which runs the risk of swap exhaustion during the fault, at which time killing a process (well, or suspending it in this odd state if you're craft) is the only option. This is trading off application stability/predicatbility for ease of resource management.
HP-UX chose a different algorithm. In HP-UX, all virtual objects in a process will already have the corresponding swap reserved... ready for whatever corresponding physical RAM they consume to be swapped out. This can reserve more swap than will actually be needed, but moves the point of failure to reserve swap (and the need to handle that failure) to system calls that create new virtual objects [mmap, malloc/sbrk/brk, etc.] which can return failure so the application can handle it gracefully. Stability/predictability over resource consumption minimization.
There is one exception to this, and that is explicit "Lazy Swap Reservation" (which is pretty much the model I described as Linux) via explicit mmap() flags, use of chatr (+z enable) on a binary.. or for some objects where the kernel may set it internally.
I think you can see where this is going -- your workload fits in your RAM for the physical data set as you'd mentioned. However, the virtual consumption of your applications (and their mmap's, etc.) is reserving all of your swap space. You won't actually use any of it until paging is needed... but it will be reserved anyway.
Hope that made sense -- if not, you may want to try reading the whitepaper [which had the advantage of more review and less 6AM, first cup of coffee], or follow up with clarifying questions.
