Desktop completely unresponsive on low memory due to stupid swapping.

[Timmmm]

This has bothered me for all of the time I have used linux. When you have swap enabled (as most people do), and try to allocate a huge amount of memory (I accidentally allocated a 16 GB array with only 8 GB of physical memory) the following happens:

1. The OS tries to allocate the memory.
2. It sees there isn't enough RAM.
3. It allocates the memory in swap, or swaps other programs out.
4. In doing so, for some reason the entire desktop becomes *completely* unresponsive. Occasionally one can get the mouse cursor to jerk around but only if you're really lucky can you get to a terminal and kill the offending process.

The OOM killer is never called because technically, there is still memory left in swap. But unless you are willing to wait hours with an unresponsive desktop that's entirely useless. THIS ISN'T A PROBLEM SPECIFIC TO MY SYSTEM. I've seen it on every single Linux machine I've ever used over the last 10 years.

It doesn't need to be this way. I have no idea why the mouse freezes for example - can the kernel really not handle swapping and bloody mouse moving at the same time? And why the hell can't it say "Oh, Matlab wants a 16 GB array? That might take some time... maybe I'll give it a low priority so that the whole freakin' computer doesn't freeze while I do it."

Srsly. And yes, I lost work because of this bug.

/rant.

[Phillip Susi (psusi)]

You seem to already realize that this is just a rant, which does not form an actionable bug report, therefore I am closing it. To answer your question, the mouse can not move because the program responsible for handling it has been swapped out.

[Timmmm (tdhutt)]

It may be a rant, but that doesn't mean that it isn't a real problem and can't be fixed. It totally *is* actionable. For example if the problem is due to X or Gnome being swapped out, surely there is a way to protect them from being swapped.

I could find anything in /proc/<pid>/ to do this, or on Google (although a few other people have asked), so it will require a kernel patch. Something like oom_adj, but swap_adj, or a per-process version of swapoff().

This IS fixable. Swapping out the critical user-interaction programs that would allow the user to kill the offending process is clearly a bug.