This is a recurring stress dream from the pre-UNIX, pre-MULTIX O/S including many IBM O/S. UNIX dies of low swap space, but low RAM is quite desirable (you paid for it, so sw that uses it all, all the time is great), since it is a cache for things on disk. When a process exits, it creates some free pages from freed swap or could-swap-but-swap-never-allocated pages, but mmap() pages like linked dynamic libraries remain in RAM awaiting other mmap() of the same file, like libc.so. If lots of stuff ends and nothing new runs, the free RAM may be substantial and persistent, but it just says you are not using the RAM and the whole machine fully, in ways that exploit the RAM you bought. Just booted systems can be a bit slugish as RAM pages get written from disk, then perk up as more of the pages needed for each new process are already in RAM. A process that mmap()'s files and reads them in excess can roll every other app's pages from RAM, a vulnerability; when it stops, they all gradually return to full responsiveness as they roll in their pages.

Some O/S map swap and /tmp together, so either files in /tmp or many programs malloc()ing lots of space (new'ing objects) can draw down the swap space to dangerous levels. You can make more swap using any local files space using mkswap or the like, in an emergency, but usually the trick is to kill the hog. Sometimes a programmer needs to do things in file space or with mmap() not malloc(), or needs to not run 983 parallel processes, but 32 at a time until all are run (I like 2x the CPU Core count, assuming 50% i/o bound processing). Disk is so cheap, so not being stingy on swap is a great direction, too. Fussing over lack of VM is not worth your time.