I hit this again today after a bug in an R program and got motivated to make a smaller test case.
Attached is a program that tries to allocate 10GB of memory by: 1 - Allocating it in MB chunks and *not* writing to them 2 - Allocating it in MB chunks and memset'ing them to 0 3 - Allocating it in kB chunks and *not* writing to them I ran this on a system with 3GB of memory and no swap. The result was that 2 and 3 eventually slowed the system down to a crawl making it very hard to even cancel the command on the terminal. Eventually the OOM killer kicked in and killed it and the system went back to normal, but not without first killing some other things. Curiously #1 worked fine. glibc is probably doing something funny behind my back as available memory does not go down when that runs. I'm not sure this is actually reproducing the problem I am reporting. The behavior seems almost normal with processes getting killed by the OOM and the system going back to normal. It was very unresponsive in the process which is my real problem. It's fine that some program slows to a crawl if it tries to get too much memory but it should impact everything else quite so much. Otherwise it's impossible to kill it and the system is effectively stalled. Would the newer cgroup stuff help with this? Does it also throttle IO? Would the R program that was causing the problem be a better example? It's a pretty short program but it wouldn't be a short test-case as it brings in all of R. ** Attachment added: "Simple test case" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/750133/+attachment/2117308/+files/test.c -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/750133 Title: The system becomes unresponsive under memory pressure even without swap -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
