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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/582264 Title: lucid lynx going into disk activity frenzy, stalls for minutes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/582264/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
