Is Swap Space Still Relevant? – Understanding Modern Memory Management

swap

I've used unix for quite a while, and for the last couple years I've felt like swap is an anachronism, but I'd be curious what other folks think.

My argument is roughly this (assuming no global ulimit or twiddling of OOM settings):

There is little value in swap because if you need to swap out to disk, 
odds are it's going to be a vicious cycle where an app will continue 
to eat not only real memory, but swap as well until it gets OOM 
reaped (_if_ it gets OOM reaped). 

If you have swap enabled, it will only prolong this death march to 
the detriment of other processes - and in the worst case where the
process is not OOM reaped in a timely manner, grind the system to
a halt.

Without swap, it will probably get OOM reaped sooner (if at all)

For any service that is tuned for performance, I would think that understanding the upper limits of it's resource usage would be key to tuning it in the first place, in which case you know how much you need.

I can't imagine many situations (some, but not many) where you'd suspend a running process and it could swap out to make room for other things, but you'd still lose your sockets if you did that, so forcing a core-dump via gcc or copying the memory out by hand would be functionally equivalent.

I definitely wouldn't want swap on an embedded system (even though it may have a smaller available ram), if you run out of ram I'd rather have my process die than tear up a million-write-per-sector flash memory drive over a weekend by wear-leveling the sectors down to the nub.

Any unix-beards out there have any compelling reasons to keep swap around?

UPDATE answers && analysis:

  • CONFIRMED? – fork() requires the same amount of memory for the child process as the parent

    Modern fork() is copy-on-write for children on POSIX (in general), but Linux and FreeBSD specifically, and I'm assuming OSX by extrapolation. I consider this part of the anachronistic luggage that swap carries with it.

    Curiously, This Solaris article claims that even though Solaris uses Copy-on-Write with fork(), that you should have at least 2x (!) the parent process size in free virtual memory for the fork() not to crap out in the middle. While the Solaris element somewhat busts the argument that swap is an anachronism – I think enough operating systems correctly implement CoW in such a way that it's more important to dispel the myth than to mark it as further justification for swap. Since. Lets face it. At this point the people who actually use Solaris are probably just Oracle guys. No offense Solaris!

  • CONFIRMED – tmpfs/ramfs files can go to swap as a convienence when tmpfs/ramfs fills up

    Don't use no-limit tmpfs/ramfs! Always explicitly define the amount of ram that you want tmpfs/ramfs to use.

  • PLAUSABLE – Have a little swap 'just in case'

    One of my old bosses used to have a great saying, 'you don't know what you don't know' – essentially, you can't make a decision based on information you don't have yet. This is a plausible argument for swap to me, however – I suspect that the types of things you'd do to detect if your application is swapping out or not would be heavier than checking to see if malloc() succeeds or catching the exception from a failed new().

    This may be useful in cases where you're running a desktop and have a bunch of random things going on, but even still – if something goes nuts I'd rather it be OOM reaped than diving into swap-hell. That's just me.

  • BUSTED! – On Solaris, swap is important for a couple of reasons

    tmpfs – states The amount of free space available to tmpfs depends on the amount of unallocated swap space in the system. The size of a tmpfs file system grows to accommodate the files written to it, but there are some inherent tradeoffs for heavy users of tmpfs. Tmpfs shares resources with the data and stack segments of executing programs. The execution of very large programs can be affected if tmpfs file systems are close to their maximum allowable size. Tmpfs is free to allocate all but 4MB of the system’s swap space.

    Solaris facts and myths about swap – states Virtual memory today consists of the sum total of physical RAM and swap space on disk. Solaris DOES NOT require any swap space to be configured at all. If you choose this option, once RAM is full, you will not be able to start new processes..

    I'm unsure if this means that the maximum virtual map you can create is ram+swap, or if you could still do something like mmap() a file larger than ram and rely on mmap()'s lazy initialization.. While you can probably run Solaris these days fine without swap, it seems like it's less friendly about it than other POSIXy operating systems.

  • BUSTED! Popular Linux hibernation tools appear to rely on swap

    By default, TuxOnIce looks like it relies on swap for hibernation – although other backends exist. However, if you're not running a box that needs to hibernate, I would still stand behind the statement that 'swap is anacronistic on linux'

Best Answer

Don't confuse (the) swap (as a disk area) and (to) swap (as a method to move memory pages from RAM to disk and reciprocally).

Excessive swapping is something to be avoided for performance reasons but having a swap area isn't necessarily a problem.

On systems, like Linux, that overcommit memory, i.e. that allow processes to allocate more memory than available, running out of RAM with not enough swap to handle the situation will trigger the OOM killer. You have to trust the algorithm used to select the "right" process to kill, and accept one or more of your processes to be killed without being given a chance to shut down properly. Here is a famous analogy that explain why the OOM killer might not be a good idea at all.

On systems like Solaris, that do not overcommit memory, i.e that make sure a memory reservation is always backed by virtual memory, whether in RAM or on disk, having a sufficient swap area is absolutely necessary otherwise a potentially significant part of the RAM will be wasted.

Related Question