[jcrites]

Even beyond that: it's desirable for a machine to be able to compute arbitrarily large data sets. If the data set can't efficiently fit in memory, the machine should still make progress, just more slowly, using disk.

It is not desirable for a machine to have a "wall" which, upon being hit, becomes a harsh restriction on its capabilities. This is because we often encounter the "wall" unexpectedly, at a time that might be critical.

[vidarh]

But they still have a wall - it's just takes a bit more to hit it. In Linux systems swap is usually 2x memory. With swap set like that, all swap does is raise the wall to 3 times what it previously was.

But for a lot of systems your service will fail shortly after you start swapping anyway, because the performance cost of swapping is so high that it often starts a death spiral (can't handle enough requests, so they start piling up, eating even more memory, until your system dies or you hit connection limits etc.).

So "best case" in a typical configuration is that the wall is a bit higher. Worst case you gain nothing at all from the swap.

Personally I treat it as a failure if we ever hit swap - it means connection limits etc. has been set too high.

[GoodIntentions]

"Personally I treat it as a failure if we ever hit swap"

/agree. but still a useful feature.

The degraded performance a system will show when it starts hitting disk instead of memory is a great 'soft' failure.

I think it is good to have graduations. Going from 'OK' to 'Damn-this-is-slow' before 'Fail' is handy.

[ars]

That's not why you need swap. Swap is because many applications will use memory when starting and then never touch it again.

You can therefor swap it out and use the extra memory for cache.

Most long term applications only need a small fraction of their startup memory.

[justincormack]

Then surely they could free it?

[ars]

If you allocate memory "after" that memory, it's not possible to return the earlier memory to the OS.

Also, suppose you need the memory only for startup and shutdown (things like logfiles, network connections, command line parsing, etc).

[justincormack]

Yes it is. Memory allocators are heaps not queues.

Things like network connections, logfiles are used all the time, so they won't be swapped out (actually file handles are kernel side so never swapped anyway). You can free the command line parse after setting the options.

And clean shutdown is overrated: long running programs can just terminate fairly gracelessly if necessary, the OS cleans everything up.

[ars]

Memory allocators might be heaps, but behind the scenes it's just an area of memory, and that area is contiguous.

If you increase the size of the memory available to you (sbrk) you can only decrease it if no memory is allocated between the new area and the end of it.

In practice the memory is never returned, and applications rely to swap to deal with that.

It's not the logfile (and network) handle that is swapped out - it's the code for deciding where it is, and opening it. Also initialization code.

Some programs can abort, but others will require a (slow) consistency check of their data if that happens to them.

And finally theory is all well and good, but in actual practice about 3/4 of the memory used by running programs can be swapped out.