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.
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.
/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.
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.
Also, suppose you need the memory only for startup and shutdown (things like logfiles, network connections, command line parsing, etc).
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.
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.
1) it needs to either be told the various sizes, speeds, and quirks on each server to make best use. (just some work)
2) it needs to coordinate with the other processes running on the system to divide up the resources. This is hard. Generally people bail and just assign some share of RAM and hope for the best with the other layers.
I guess I want to argue that with the currently typical amounts of RAM, all critical data should fit in RAM and stay there. The idea of virtual memory was to abstract over the difference between RAM and disk, but perhaps this has become a harmful abstraction now that RAM is big enough while the disadvantage of slow disks remains. RAM and disks are fundamentally different parts of the memory hierarchy, and should be treated completely differently by applications.
If they never modify those CoW pages, they can both happily keep using the same copy of the page in memory, and you can have two 1GB processes using a total of e.g. 1.01GB of real memory.
This is very useful in practice, but it means that the system needs the ability to over-commit memory allocations (allow CoW allocations etc., when there is no actual memory available to back it), and over-commit currently, and probably should, requires swap (some place to dump pages in case an over-committed allocation comes calling).
If you have 16GB of ram, and 0GB of swap, the OOM killer will kick in at 16GB.