At some amount of active memory use Linux will grind to a halt. This happens with or without swap. It's a problem of how it handles low memory situations.
But if you have swap, this point comes much later. Often many gigabytes of unimportant data can be moved out of memory. If you can swap out 6 gigabytes without causing problems, and you only needed an extra 4 gigabytes of ram, then swap saves your day with almost no downside.
Your system would grind to a halt anyway; swap is simply giving the kernel more options to deal with the issue. Without swap the kernel has no options when it cmes to unreclaimable pages.
I didn't enable swap for the first 6 months, every time I ran out of memory the system froze. Now I use swap and only the offending applications do actually freeze. There is a small problem though, one application in particular permanently captures the damn mouse in fullscreen mode so if it freezes I can't interact with the rest of the system with the mouse but this is purely a bug in the application, not a problem with the operating system.
Well, it's more of a design problem of X11. Under Wayland, the compositor could offer a Secure Attention Key like Ctrl-Alt-Del that reclaims input focus from a fullscreen application. As far as I'm aware, such facilities do not exist in X11. When an application grabs the keyboard, it's grabbing the entire keyboard.
Yes, the problem is that X11's login/lock screen is secured by grabbing the keyboard and mouse, taking away input focus from the login screen in many cases will allow you to bypass it entirely.
Such facilities actually do exist in Xorg, they are just disabled by default. But you can configure the server with a shortcut key to release input grab.
i would venture a guess that probably you saw something like for example large JVM being partially swapped on HDD - in a situation like that it isn't swap per.se. which is at fault, it is the fact that JVM memory access pattern - randomly jumping all over - is extremely unsuitable for HDD based swap.
Actually, there is a critically bad interaction between the way that garbage collection algorithms work and the LRU heuristic for swap. Tracing garbage collection algorithms work by doing a graph traversal that traces all the live pointers starting from the "root set" (ie, pointers in registers and on the stack) to find all the live objects.
Now, note that (a) the root set are the hottest objects in memory, and (b) they are the ones that gc algorithms touch first. As a result, when you are doing a gc, the LRU (least-recently-used) heuristic for managing swap ends up putting all the hottest data in the program onto disk. This is pretty much the pessimal thing for the kernel to do, and can tank performance by triple-digit factors.
However, this is entirely fixable!
The gc and the kernel need to cooperate to figure out what is okay to push to disk or not. Matthew Hertz, Yi Feng and Emery Berger have a really nice PLDI 2005 paper, Garbage Collection without Paging, which shows how you can make gc performance hundreds of times better with just a little kernel assistance.
However, because kernel developers do not program in garbage collected languages (they program in C, because that's what the kernel is written in), they don't understand garbage collection and are hostile to kernel changes to support it. Emery Berger told me they tried and failed to get the Linux kernel to support their changes, and people who worked on .NET told me they had similar experiences with the Windows kernel team.
