Comment 33 for bug 582264

The problem's still present in 2.6.38, though the stalls are much shorter. The longest one I've had until the OOM-killer did its job was about 12 minutes.

Stephane Carrez suggests changing the I/O scheduler to the deadline scheduler:

http://blog.vacs.fr/index.php?post/2010/08/28/Solving-Linux-system-lockup-when-intensive-disk-I/O-are-performed

This can be done on a per-disk basis like so:
echo deadline > /sys/block/sda/queue/scheduler

Or the default can be changed by setting the kernel option elevator to deadline at boot time. So presumably, in grub.cfg, instead of:

linux /vmlinuz-somethingsomething root=somethingsomething

It should say something like:

linux /vmlinuz-somethingsomething root=somethingsomething elevator=deadline

The kernel developers have obviously thought long and hard about what scheduler to choose, but if the deadline scheduler can prevent the system from stalling for up to 12 minutes each time it runs out of RAM, with or without swap, then it's possible that the deadline scheduler would be a better default choice.