Created attachment 22499 [details] Trigger the freeze. Hello, since a while (at least 2.6.28, maybe longer) I have a reproducible problem with the memory manager. I have 2GB of RAM, and a 6GB swap partition located as a logical volume on an LVM whose physical volume is a luks-encrypted hard drive. The device is a Lenovo T400 with two cores, running an amd64 kernel. As soon as the memory is filled up an the kernel starts to swap, the system becomes utterly unresponsive, i.e. not even the X mouse would move. SysRq-B would reboot the system, but it would take ~20s for it to react. If I disable the swap, shortly before the memory filling application is killed, the system is also very slow, but I can still move the mouse or change windows. Constantly running cat /proc/swaps every 100ms while filling the RAM showed me that there is 28 kb in RAM before the system freezes. Of course it might be a little bit more there, but the cat did not not have a chance to print it. I’m running the kernel as provided by Debian in the unstable distribution, based on 2.6.30.2. I was told by a member of the Debian kernel team that there are no patches applied by Debian that would affect the memory manager. I have attached a simple program that triggers this behaviour. Thanks, Joachim
I find this also on an Ubuntu 9.04 distribution using the 2.6.30.4 kernel on a laptop with 4GB RAM and a 4GB swap partition, but it is _much_ worse using the 64 bit kernel. X is still reasonably responsive under the 32 bit kernel, but in 64 bit it often freezes so badly that I have to reboot. I opened http://bugzilla.kernel.org/show_bug.cgi?id=13205 about it some time ago.
Running 2.6.32 now. I just had a memory-hoggin application and the system successfully filled the swap and then killed the process. The system was hardly responsive while swapping, but it did not crash. It seems that this bug has disappeared. rocko, can you confirm this?
Yes, 2.6.32 is much better for me (as in X doesn't freeze when using swap), and 2.6.33 better still. There was a lot of work on the CFQ scheduler in these kernels.
I confirm that I had this problem with matlab for many years now. It is the worst linux bug I can think of. I use a 64 bits 2.6.32 kernel, the ubuntu lucid version, but I had the same problem with previous versions of ubuntu running on 32 bits machines. Every time I use matlab, if by mistake I use all the memory, the machine freezes and I have to reboot. It is incredibly easy to reproduce. The hard drive starts making a lot of noise. The funny thing is that, exactly because of this problem, I have not been using swap for the past three years, but nevertheless the hard drive is still making a lot of noise. I have no idea what is going on. Given enough time, maybe hours, eventually matlab gets killed. I would love to know why the kernel crosses my decision to have no swap and use the hard drives anyway. How can that be overruled?
Not a bug, but configurable behaviour which it's up to the distribution how they set. See vm_overcommit.