Comment 1 for bug 159356

I can confirm this in general for every linux distribution I've ever used. Any time I have a process that is both using 100% CPU and eats up memory, the system becomes unusable as soon as it starts using swap. At this point the hard drive starts thrashing and X slows to a crawl (the pointer updates maybe every 30 seconds). My only options at this point are to 1) hope the program finishes and gives some memory back, 2) wait for swap to fill completely so the kernel will kill the program, or 3) reboot the computer. The latter option is usually 5-10 minutes faster. I think this is a very meaningful bug report, and one that I'd love to see some attention given to, although I have no real idea what the solution might be. The only workaround I've found is just to disable swap completely (I'll bet your swap just wasn't enabled on your 32-bit box?).

Of course it's expected that things will perform badly when the system is out of memory, but it's pretty rediculous that as soon as RAM is full there aren't even enough resources for me to get to a console, log in, and kill the program myself. It seems to me that if one program is spending all of its time writing swap pages, there should at least be plenty of CPU left over for me to operate the mouse, so it seems like there's something else going on that causes the system to crawl..

So the question is: can we come up with a reasonable fix for this problem, or do we just accept that any runaway process can crash the machine? For the time being, I'm happy running swapless.