Bug 13205
| Summary: | System becomes unresponsive on heavy RAM/swap use | ||
|---|---|---|---|
| Product: | Memory Management | Reporter: | rocko (rockorequin) |
| Component: | Page Allocator | Assignee: | Andrew Morton (akpm) |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alan, mikhail.v.gavrilov, nfxjfg, peterhoeg, rockorequin, stellplatz-nr.13a |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 3.2.6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | C++ Utility to allocate chunks of memory of user defined size in MiB | ||
|
Description
rocko
2009-04-29 05:25:12 UTC
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 |