I'm running Ubuntu 9.04 with the 2.6.30.rc3 kernel on a laptop with 4GB of RAM and 4GB of swap. When I run three VirtualBox (version 2.2 PUEL) VMs each with around 1.4GB of RAM, as soon as the kernel starts to use swap (as shown by atop -d) the system effectively becomes unusable - the HDD thrashes away, X windows stop responding, the keyboard stops responding, you cannot ssh in from another PC. I can move the mouse, but only very slowly and in staccato fashion. The gnome-terminal running sudo atop -d seems to stop refreshing after it indicates that about 300MB of swap is in use. Clicking on windows to try and close them has no effect. The only solution is to hard reset the machine. I have waited up to 15 minutes to see if things would improve. I would expect that at the very least I should be able to access gnome-terminal or a VT console and manually kill processes to make the system usable again; at best it would be great if memory management could detect such a condition and take some action like freezing memory-hungry processes. This occurred also in earlier kernels, eg 2.6.27 (Ubuntu 8.10) and 2.6.28 (the stock kernel in Ubuntu 9.04). I'm guessing this is something to do with kswapd but I don't know which part of memory management this might fall under, so I'm just going to guess at page allocator.
Created attachment 21370 [details] C++ Utility to allocate chunks of memory of user defined size in MiB
I have very similar problems and would like to add the following references: http://bbs.archlinux.org/viewtopic.php?pid=390313#p390313 https://bugs.launchpad.net/ubuntu/+bug/283420 https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/159356 Could you also consider the following (quoting my own LKML posting from 2009-05-11 1:58): **** To reproduce this, I've attached (above) a small C++ utility (compiles with g++ memory_overcommit.cc -o memory_overcommit.bin) which allocates chunks of memory of user defined size. (Also here: http://datenparkplatz.de/DiesUndDas/memory_overcommit.cc) On the Ubuntu system, the system freeze can be observed with swap enabled on a cryptographic swap partition (dm-crypt; /etc/crypttab). With openSUSE the lock-up also occurs with deactivated swap. (swapoff -a). Tested from a KDE terminal window as regular urser, the steps to reproduce are: * use cryptographic swap partition or disable swap (maybe also reproducible with normal swap; but apparently not on Suse) * compile and invoke the attached code: ./memory_overcommit.bin * enter a number (in MiB) of memory that is slightly smaller than the available memory and press "enter" key once. * enter a smaller number (minimum 1 MiB) and confirm again, do the same again,..., successively approaching the limit of available memory with smaller chunks. * finally, when most of the memory/buffers/cache are used-up, the system becomes unresponsive and constant, heavy harddisk-access commences. Sometimes, more than one attempt is needed to yield the behaviour.
I installed an i386 kernel (2.6.30.4 configured to use PAE) to compare to the 64 bit kernel (2.6.30.4) and ran some comparison swap tests between them: * I started up two VBox VMs taking up approx 2 GB between them and waited until disk activity settled. * I told file-roller to tar /usr/src/linux-2.6.30.4. This process takes up an ever-increasing amount of RAM (I assume it's because of some symbolic links that link back into the same folder - I've got /usr/src/linux linked to /usr/src/linux-2.6.30.4). X under the the 32 bit kernel is still reasonably responsive, even when it is swapping and file-roller is taking up around 1.5GB of RAM and 2.5GB of virtual memory. (file-roller vanishes without warning when it gets to about 3GB of virtual memory.) X under the 64 bit kernel just about freezes completely _as soon as_ it starts swapping. Since file-roller doesn't die, I have to hard-reset the system unless I have the patience to ssh in and kill it manually (which takes five to ten minutes, the system is so unresponsive).
Also, http://bugzilla.kernel.org/show_bug.cgi?id=13849 looks like it might be related to this bug.
I think I ran into this problem again with 2.3.34-rc3. The drive went crazy and the system was for all intents and purposes unusable. It hasn't happened in 2.6.33, however.
And of course I meant to say 2.6.34-rc3, not 2.3.34-rc3.
I am seeing this on .35 and .36 as well on two different machines.
I have his problem in 3.2.6, and I think it didn't exist on 2.6.32. As soon as an application requests more RAM than what is physically free, the system gets mostly unresponsive. X freezes, you can't even move the mouse cursor, and it takes a long time until it unfreezes. This happens even if the amount of memory requested by the application is relatively small (like 200 MB). I wonder how it is possible that X freezes in this case, even if it's not doing any disk I/O and likely isn't doing any large memory allocations. I'm not swapping to an lvm/luks partition.
I've seen it happen in 3.4 as well, but the kernel behaves considerably better than in the 2.6.32 to 2.6.36? kernels where I originally experienced the bug. The system does freeze but it is only for 30 seconds or so, whereas in 2.6.32 I gave up waiting after 15 minutes.
This bug relates to a very old kernel. Closing as obsolete.
Alan,new kernels having problem with swap too Described here: https://bugzilla.kernel.org/show_bug.cgi?id=60533
Thats fine they have their own bug